https://open-source-silicon.dev logo
Join Slack
Powered by
Have a few questions re ChipIgnite mixed-signal ca...
# mpw-6plus-silicon
a
Have a few questions re ChipIgnite mixed-signal cases (in my case chipignite run 2211Q). I am planning on designing a PCB to interface with the chip (using bare dies) and need to confirm a few points: 1. My design does not use the on-chip risc, is this still required to configure the GPIOs or not all? 2. I set my GPIOs via the user_defines.v file which should be set during startup - assuming my user_defines.v is correct, am I right in thinking I don't need the risc at all? a. If I'm right, I would be able to test the chip without needing ftdi & flash at all. 3. If I'm wrong above, I need to design my PCB to be able to use FTDI & flash to code the risc processor. By the looks of it from the schematics here https://github.com/efabless/caravel_board/tree/main/firmware/chipignite#readme I can connect to the pin headers for ftdi/flash of the board provided to get that function. Is this correct? 4. Unfortunately I will need 5V on vddaX for my application. Can I have vdda1, vdda2 @5V, and vdda @ 3.3V to enable me to interface with FTDI & flash at 3.3V whilst having 5V for my application? I will have vddio @ 5V as well. Which means vddio will also have to be 5V. So if I'm wrong for 1 & 2 above, I will either have to power up at 3.3V, interface with ftdi/flash to set up gpios & then ramp supplies to 5V (applies to all 5V supplies), or risk it and interface SDO for FTDI / flash at 5V enabling their esd circuits (should be current limited by the driver). Am I understanding this correctly? @Tim Edwards?
Just realised I'll probably be able to use a level translator between caravel & the other interfaces to not have to play with supply levels, i.e. set caravel side @ 5V, other side (ftdi/flash) @ 3.3v via a bi-directional translator
t
Yes, the whole reason for the "user_defines.v" is that it allows a user project to run independently of the management SoC and you don't need to have a program running at all and can force the clock off and leave the whole chip in reset. You can have any 
vddaX
set to 5V and still run 
vddio
at 3.3V. Is there a reason that doesn't work for you?
There are no current paths (outside of what might be implemented inside a user project) between 
vddaX
, 
vccdX
, and 
vddio
. There is no interaction at all between the user 
vddaX
supplies and the management supplies. The management side 
vdda
isn't even connected to anything except some analog switches inside the GPIOs which hardly anybody knows how to use.
a
You can have any 
vddaX
set to 5V and still run 
vddio
at 3.3V. Is there a reason that doesn't work for you?
I didn't even think this was possible as I thought that 
vddio
is used for ESD for all pads (hence should be @ highest voltage). After both of your comments, I used the board provided and software to check a packaged chip under that configuration, i.e. 
vccdX=1.8V
, 
vddaX=5V
, 
vddio=3.3V
, and the rest at default ( 
vdda=3.3
, 
vccd=1.8
) - can confirm no magic smoke, and a few of the analog pads where driven to 5V internally (core -> pad) with no issues. Thank you for the help!
t
@Andrea Mifsud: It doesn't work for them because they added two monitoring signals from each side of the flying capacitor and connected them to the analog connection of two GPIOs. The high side of the cap then approaches VH and the ESD diode of the GPIO with the monitoring signal sinks current from VH (5V) to VDDIO (3.3V).
a
@Tim Edwards not sure I understand what you mean for your last comment?
From what I can see, if you use the analog pads in caravan (I could only check io_an[7], & io_an[8]), I can get a 5V driven from the user area all the way to the pad (say io_an[7]) and measured with a multimeter with the chip under these conditions 
vccdX=1.8V
, 
vddaX=5V
, 
vddio=3.3V
, and the rest at default ( 
vdda=3.3
, 
vccd=1.8
). If standard GPIOs are used - I don't know what happens (analog-wise, I only used 1 GPIO as analog, just to sink a current from a 1.8V supply which is within VDDIO ESD and have no issues)
t
I confused this thread with another one and so yes, my comment doesn't make any sense at all.
vddio
is used for ESD for all GPIO pads but there is nothing (outside of the user project) connecting it directly to the 
vddaX
domains. There are back-to-back diodes between the grounds, but no such coupling between the power pins, which is what allows 
vddaX
to go higher than 
vddio
. There is a high voltage clamp circuit on the 
vddaX
pins, so I don't think it can go higher than 5.5V without something breaking down in the clamp circuit. However, if you powered some circuit in the user project with 
vddaX
and then connected an output signal from that circuit to a GPIO pad, then there is a path from 
vddaX
to 
vddio
and 
vddio
must always be greater than or equal to 
vddaX
.
👌 1
Open in Slack
PreviousNext
Powered by