Lattice's Unintended Darwinism in Tech Support
Roadblocks using VHDL on ICE5 with Lattice Tools
VHDL itself is completely generic, but the target FPGAs often have highly specific special functionality. For example you may use the multiply operator in an expression, and the compiler may produce a discrete logic multiplier; but the FPGA itself may have much more efficient hardware multiplier instances. Generic VHDL internally has no way to know or choose about that, or even between the many different kinds of discrete multiplier design that it could generate with different tradeoffs.
To get around it, the vendor provides canned component names + generics / ports representing IPs that are hard macros on the FPGA, to make the compiler wire up what you want, you explicitly instantiate these "magic name" components. (That gets you sometimes a very very long way away from VHDL's "write once synthesize anywhere" promise as more and more platform-specific FPGA features get dragged in)
For that, you need the equivalent of C's function prototype, giving the correct name of the canned macro and the correct argument names and meanings.
Lattice and VHDL
I already have some of these canned macros in my design, but for many in the canonical library documentation for ICE5
There are no details for VHDL, only Verilog. You can see from the filename the latest version of those docs are from April 2015, ie, 1.5 years ago.
For example for SB_IO, the IO cell, on p71 it gives Verilog only and omits VHDL.
The only other pdf reference I could find to IO cell instantiation was TN1253
about differential IO, again in there just Verilog, for VHDL it says
VHDL
Under development.
This current document is 20 months old, from Jan 2015.
Despite how it looks, VHDL is otherwise a first-class citizen with Lattice, and I was able to find other components documented and use them with VHDL. And my tools from Lattice are more modern than the docs, from Feb 2016 which is encouraging.
At the bottom of it, it says
Technical Support Assistance
e-mail:
techsupport@latticesemi.com
Internet: www.latticesemi.com
Glimpse of a Frozen Hell
I sent them an email referring the documents and explaining the problem, and asking for the . After a while I received the reply
Thank you for your email. If you have sent the email for technical support, we request you to submit your request through our Technical Support Portal on the Lattice Semiconductor Website (www.latticesemi.com\techsupport). The Technical Support Portal allows users to enter their cases directly in the Lattice Technical Support tool, check status of their cases, update their cases, and view their old cases.
PLEASE NOTE THAT THIS MAILBOX IS NOT MONITORED SO YOUR QUERY WILL NOT BE ADDRESSED.
So the first sign all is not well was the old docs not being updated with the info in the first place.
The second sign is their current docs provide a support email alias they don't support any more (and have not updated their docs).
I rewrote the question in their web-based system, which says this as the first thing
Please be advised that highest priority for Lattice Technical Support will be given to:
1. Software which is not working as expected or suspected bugs.
-We recommend that customers use the latest software tools and follow the system requirements specified in the tool’s Software User Guide.
-When submitting software issues you will be asked to provide the software version, operating system details, exact steps for how to recreate the issue, provide an example project to recreate the issue if possible, and send us the log file as applicable.
2. Questions and problems related to datasheet, timing, functionality, device compatibility, and general application support requests like schematic review, programming cable issue, etc.
3. Any modifications or changes to existing Reference Designs, IP, demos, and solutions beyond the guidelines specified in the User Guide are responsibility of the user. Lattice reserves the right to select the appropriate updates that apply to a generic solution.
This is where the Darwinism comes in... this list is a function describing the "fitness" of your question to be dealt with by Lattice. I think some kind of triage about support questions is normal, but there is no understanding in that list that the reason people are forced to ask questions may be because your documentation is inadequate and must be improved.
As such, Lattice have made questions that should provoke documentation updates extinct. That's why their docs are still incomplete and not useful for the VHDL case after getting on for two years.
Every user who wants to use ICE5 with the IP assets on the FPGA without documentation for VHDL, faces the same problem, over and over. As such, multiplying the issue by the number of people affected and the number of support questions dealing with it properly would eliminate in future, correcting failures in Lattice documentation should be #1 on the list.
Looking at the headers, the messageid is "...@agiloft.com", that seems to be a customer support outsourcing company; the Lattice tools come from Synopsys and Silicon Blue, except "Ice Cube 2" which is a flow manager on top of the other tools, and very basic integrated editor (and no simulator if you're on Linux, only Windows... that makes zero sense). Basically it seems everything is outsourced with a little glue.
Work around
I found by digging around that you can find the component prototypes in the compiler tree here
./lscc/iCEcube2.2016.02/vhdl/sb_ice_syn_vital.vhd
The actual DDR SB_IO instantiation needs to look like this kind of structure, per IO
drd0008: SB_IO
generic map (
NEG_TRIGGER => '0',
PIN_TYPE => "100000",
PULLUP => '0',
IO_STANDARD => "SB_LVCMOS"
)
port map (
PACKAGE_PIN => RD0,
LATCH_INPUT_VALUE => '0',
CLOCK_ENABLE => '1',
INPUT_CLK => clk0deg,
OUTPUT_CLK => clk0deg,
OUTPUT_ENABLE => r_data_oe,
D_OUT_1 => r_data_write(0),
D_OUT_0 => r_data_write(8),
D_IN_1 => r_data_read(0),
D_IN_0 => r_data_read(8)
);
"PACKAGE_PIN" is the signal with the toplevel port you want to bind the SB_IO definition to.
See my article "Hyperbus implementation tips" https://warmcat.com/embedded/hardware/lattice/hyperbus/hyperram/2016/09/19/hyperbus-implementation-tips-on-ice5.html for other information about implementing hyperbus / hyperram on ICE5.
What we learned this time
Lattice IP library docs always seem to contain Verilog component information, but don't always take care about VHDL component prototypes so the IPs can be used in VHDL. That includes critical IPs like IO cells.
Lattice support triage doesn't lead to the root cause - the documentation - being fixed, the same problem has been going for ~ two years, creating continuous difficulty for everyone using VHDL with ICE4/5 with Lattice tools.
You can find the necessary prototypes in the tools tree by digging it out yourself, and the info here will get it to compile and place and eventually work.
If you do the digging, there are enough pieces there to get a proper DDR bus interface inside the FPGA in VHDL, and operate Hyperram at 64/128MHz DDR reliably
Again the quality of the actual FPGA is very good