<ironsteel>
Hi guys, anyone tried the SPI flash on the ecp5-env board with trellis? I'm kind of confused what tool I need to use to be able to write the bitstream to the SPI flash (ecppack with --spimode option and openocd?). Also I know there are some dip switches for selecting the ecp5 FPGA configuration mode, so I need to configure them properly in order for the FPGA to read it's bitstream from flash.
<daveshah>
It's the only open tool for ECP5 SPI flash programming at the moment
<ironsteel>
daveshah, woah that was fast! Awesome! Thanks. Is there an incentive to add this to trellis at some point? like a separate command line utility for converting and programing the bitstream to the flash (like iceprog)? Or this is not generic enough to be a separate tool?
<daveshah>
The problem is that the current approach is to generate an SVF file
<daveshah>
This isn't the correct approach for SPI flash programming - that script has to include a maximum wait after each page rather than just checking the busy flag
<daveshah>
So it needs something more interactive than just SVF. This means having to either find a JTAG library that isn't rubbish or implementing JTAG and the FTDI stuff
rohitksingh has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
<ironsteel>
I see.... Does that also apply for the ulx3s? I saw that they have a separate tool (ujprog or something like that), I suppose they do the same like in the gist you linked?
rohitksingh has joined ##openfpga
<daveshah>
I think ujprog can do it for the ULX3S
<daveshah>
But that has a different kind of FTDI chip
rohitksingh has quit [Remote host closed the connection]
Bike has joined ##openfpga
<ironsteel>
trying to figure out if trellis supports using the SPI config pins as general purpose IO and if the USRMCLK macro is supported. The ECP5 sysConfig datasheet mentions persistence bits for controlling whether or not to enable the SPI pins as general purpose pins
<daveshah>
Yes, USRMCLK is supported and available by default
<ironsteel>
i suppose trellis sets these bits to 0? ah cool. So after the device finishes loading I can use the SPI pins as GPIO's?
<daveshah>
Yes
<ironsteel>
Thanks again!
lutsabound has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
mifune has quit [Ping timeout: 265 seconds]
emeb has joined ##openfpga
mifune has joined ##openfpga
ironsteel has quit [Remote host closed the connection]
ironsteel has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
<pepijndevos>
What kind of things will you run into when making an ASIC from a design that works on FPGA and simulation?
<emeb>
differences in timing between FPGA and ASIC
<emeb>
ASIC needs clock tree synthesis which is built in on FPGA
<emeb>
ASIC I/O libraries may not support the full range of functions available on FPGA
<emeb>
ASICs usually don't have the same block RAM and DSP cores available on FPGA
<whitequark>
ASIC memories would usually be instantiated, right
<emeb>
Yes
<emeb>
Either you buy RAM cores from IP vendors, or (if you're lucky) the foundry has some available
<whitequark>
there's some open-source options too
<emeb>
Interesting. So someone has "open source" hard macros for RAM that target various foundry processes?
<emeb>
Could work, if the compiler is compatible with the foundry process you're using.
<rombik_su>
IMO, from HDL coder standpoint there's not much hassle converting a design to ASIC than porting it to different FPGA vendor.
<emeb>
for pure HDL designs that may be true.
<whitequark>
rombik_su: you've did a few tapeouts, right?
<rombik_su>
whitequark: my second HDL freeze would be in 2020Q3 to be precise. Going from ARM to RISC-V on this run. :3
<whitequark>
neat
<emeb>
I've done about a dozen ASIC designs.
<rombik_su>
Thats cool! I would like to ask: what nodes/fab did you run?
<emeb>
The last one I did was a few years back. We built it on 0.18u TSMC
<rombik_su>
Our first was TSMC 40LP (mainly from cost reduction standpoint), second will be 28 nm probably.
<emeb>
what EDA tools do you use?
<rombik_su>
We partnered with physdesign company, they're using Cadence flow.
monochroma has joined ##openfpga
<emeb>
The teams I was on did our own physical. Used both Avant!/Synopsys and Cadence depending on what company I was with.
<rombik_su>
Re 'memory compilers': I heard that (and it was so in our case) if you'll buy couple of big cores (DDRx/PCIe) from a big vendor, they'll will hook you up with some smaller products like memory compiler or AMBA interconnect for free.
<emeb>
yep. bundle deals are not uncommon.
<emeb>
It's all funny munny
<rombik_su>
Looking at PCIe IP cost, it's mind boggling how silicon vendors in low-end consumer market manage to stay alive and make profit.
<emeb>
heh. pretty $$$?
<rombik_su>
I heard it's something like ~$0.5M for 28nm
<emeb>
Not surprising. Considering that even mask tooling for a full custom design on newer process nodes can be in that range.
<emeb>
perhaps a lot of low-end consumer apps are done on older nodes w/ cheaper IP.