Lattice iCE40 Bitstream Reverse-Engineered

[hamster_nz]

This would be less of an issue if it weren't for the the near-impossibility of easily specifying the logic state you want a node to be at powerup.

erm.?

Code: [Select]

signal foo: std_ulogic := '1';

There, done.

He might be on one of those FPGA types that are more ASIC-like and don't allow you to specify an initial value for flip-flips, and force you to have a reset.

If so, then that isn't the problem of the language, but due to decisions taken by the FPGA designers when they decided on their programmable logic architecture.

[Bassman59]

Can you define pin settings in Verilog? I have not been able to figure it out. I am also using the Lattice toolchain. Been doing it from the spreadsheet view which I find really annoying. I have a KiCad project that knows all the pins, my CPLD pins depend on the board layout so I would really like KiCad to drive that, so I don't have to manually define them.

Why would you want to define the pinouts in the HDL source? That makes the design non-portable. Pin definitions belong in the implementation constraint file.

I suppose a Python script which can take the eeschema files and parse it to find your FPGA pinouts and then update the .ucf file would be clever indeed. (There's a way to do this in Altium.) But you have to ensure that you choose valid pins for things; you don't want to move your clock to a non-GCLK pin because it makes your layout easier.

[c4757p]

hamster_nz: indeed, many of the complains seem like they would be better directed at Lattice. Funny, he usually pooh-poohs any suggestion that Lattice themselves are archaic or otherwise a ball-ache.

Here on the Xilinx+Altera side, all these complaints have been solved. (Well, except for the IDE sucking, but all manufacturer-provided IDEs do that.)

[Bassman59]

This would be less of an issue if it weren't for the the near-impossibility of easily specifying the logic state you want a node to be at powerup.

erm.?

Code: [Select]

signal foo: std_ulogic := '1';

There, done.

He might be on one of those FPGA types that are more ASIC-like and don't allow you to specify an initial value for flip-flips, and force you to have a reset.

That bit me. I took some code I had written for a Xilinx part, which has initializers as part of the signal declarations and also used synchronous resets (where neeed), and ported it to an Actel ProASIC-3L part, which doesn't make use of the initializers as part of the FPGA configuration and the flops don't support a synchronous reset (Synplify built it with logic in front of the flops' D inputs). Recoding was a pain, but it was necessary because the sync reset killed performance.

If so, then that isn't the problem of the language, but due to decisions taken by the FPGA designers when they decided on their programmable logic architecture.

Exactly.

[Muxr]

Can you define pin settings in Verilog? I have not been able to figure it out. I am also using the Lattice toolchain. Been doing it from the spreadsheet view which I find really annoying. I have a KiCad project that knows all the pins, my CPLD pins depend on the board layout so I would really like KiCad to drive that, so I don't have to manually define them.

Why would you want to define the pinouts in the HDL source? That makes the design non-portable. Pin definitions belong in the implementation constraint file.

I suppose a Python script which can take the eeschema files and parse it to find your FPGA pinouts and then update the .ucf file would be clever indeed. (There's a way to do this in Altium.) But you have to ensure that you choose valid pins for things; you don't want to move your clock to a non-GCLK pin because it makes your layout easier.

Right, I wasn't looking to do it in the same HDL source file, but I just learned of constraint files. So that answers my question, thanks!

Yeah I will write a script to do it automatically, sure I still have to make the decision which pin gets what, when I am laying out the PCB.

edit: btw for the benefit of others who are learning like me, here is an example of a parameterized project for the Lattice toolchain. http://www.trifdev.com/downloads.htm . I am all set.

[Muxr]

hamster_nz: indeed, many of the complains seem like they would be better directed at Lattice. Funny, he usually pooh-poohs any suggestion that Lattice themselves are archaic or otherwise a ball-ache.

Here on the Xilinx+Altera side, all these complaints have been solved. (Well, except for the IDE sucking, but all manufacturer-provided IDEs do that.)

I have limited experience with FPGAs/CPLDs but so far Lattice's CPLDs have been awesome for the project I am working on. Their MachXO2 line has versions with 3.3v voltage reg built in and you can easily get them from Mouser for $4-5 a pop. Their development board is only about $20 and it's as barebones as it gets, so it's perfect for quick prototyping or even a permanent bodge job.

[c4757p]

Yes, a common dichotomy in programmable logic. Everyone has either good hardware or good software, not both. Lattice's software sucks. (Some of their hardware does too. MachXO2 look cool, though.)

[daqq]

Nonsense. There is no real barrier to using an FPGA in an OSHW project that an OS toolchain would remove. Everyone can access FPGA tools at minimal cost.

To be fair, the bigger devices are supported only by the costly versions of stuff - atleast for Xilinx. Dunno about the rest, Altera, erm, Intertra?.

I never really got this - what's the point of not publishing stuff like this? From a chip manufacturers point of view it seems the best course of action would be to ensure that ALL of my tools area available to everyone, free of charge. Or atleast MASSIVELY support open source initiatives like this.

The availability of free or cheaply priced tools is a big issue for me, I assume the same goes for others.

The big-parts issue isn't really an issue here as we're talking parts with multi-hundred dollar price tags, in big BGA packages which need umpteen PCB layers to route. If you're making that kind of investment, a few $k on tools is chickenfeed. I suspect the reason for this is that they can use it to subsidise providing free tools to lower-end users.

You are forgetting about salvaged stuff, reverse engineered, hacking... also, I've seen hobbyists do some really amazing stuff at home.

[mikeselectricstuff]

Not every language has block comments
; any editor that isn't incompetent can still comment off a block.

I shouldn't have to change editors because of inadequacies in a language

Is it too bloody much that you use the right hammer for your nail before you start whinging about the nail?

If nobody complains, people will assume all is OK when there is scope for improvement. Things like block comments are useful for making code readable, as well as allowing quick nondestructive removal of sections for debugging and there is no excuse for the lack of it in a language.

This would be less of an issue if it weren't for the the near-impossibility of easily specifying the logic state you want a node to be at powerup.

erm.?

Code: [Select]

signal foo: std_ulogic := '1';

There, done.

Nope - this didn't work. A while ago I spent a lot of time trying to solve this elegantly and ended up having to do a bodge.
The situation was that I wanted a signal that was '0' at powerup , changed to '1' on a particular event and stayed in that state forever.
As I was never explicitly assigning it to '0 ', it minimsed the logic to nothing and set it permanently high. It ignored the attempt to intialise it as you suggested.
It's a while ago now but I think the only way I could force the state was to make it part of a 2-bit counter which got incremented if the previous value was 0.
This may be a limitation of the toolchain rather the language itself, though I did get the impression from some newsgroup messages that I wasn't alone in having trouble doing this.

Build variants include FPGA type and pinouts. You should be able to specify these in the  HDL.

This is done in the constraints file. I really can't imagine you have too much issue with having one separate file for that?

I don;t have a problem having the file seperate. The problem is  (at least in Lattice Diamond) I can't specify the FPGA partno in the file and I also can't do conditional pin assignment based on a constant build option symbol that is visible to the HDL and CF.

If I could specify everything in the HDL, do #define and #include etc.  I could so something along the lines of

#define  variant 2
#if variant=2
fpga_type="LCMXO2-100"
#include pinout_for_version_2.inc
constant ram_size_bits:integer=10;
#endif

etc.

[mikeselectricstuff]

hamster_nz: indeed, many of the complains seem like they would be better directed at Lattice. Funny, he usually pooh-poohs any suggestion that Lattice themselves are archaic or otherwise a ball-ache.

Here on the Xilinx+Altera side, all these complaints have been solved. (Well, except for the IDE sucking, but all manufacturer-provided IDEs do that.)

I only quote Lattic beacuse that's what I know - I used ISE a while ago and it looked pretty much identical - maybe it's better now. Never used Altera as they'v historically not had many low-cost parts.

Let me give some background as to why I find FPGA stuff frustrating.

I only use FPGAs very occasionally - maybe a week or so every few months, so I'm not intimately familiar with things. My FPGA designs are typically very simple as these things go - typically stuff like generating the waveforms for driving LED matrices etc.
I understand hardware. I know exactly what I am trying to achieve, but I often find it a frustrating  process making it happen, and a variety of factors contribute to making it harder than it should/could be, from the language through the IDE.

Why do I want #define and #include ?
For exactly the same reason it's there in C. HDL isn't a programming language, but the way it's used in the context of an FPGA hardware project is no different, so it ought to be possible to use the same techniques to do the same type of thing.
 
It would mean I can specify options in a way that is consistent across all sections of the design, from signal declarations constraints to sync and async logic and easily omitting sections. Yes I can do _some_ of it with constants, but not all. And not all in the same way in different parts of the design.

 
 

[nctnico]

In VHDL you can create a package which has global constants (much like a header file in C). Based on these constants you can use if - generate blocks to include or exclude certain pieces of VHDL code. The same goes for the width of busses. I have used these kind of techniques to keep my FPGA designs configurable. I always say that the key to use VHDL effectively is to treat it as a programming language and not to use it to describe hardware.

Anyway, I think it is good to have open source FPGA tools. People can bolt on their own extensions more easely like running their design files through a pre-processor.

[mikeselectricstuff]

In VHDL you can create a package which has global constants (much like a header file in C). Based on these constants you can use if - generate blocks to include or exclude certain pieces of VHDL code. The same goes for the width of busses. I have used these kind of techniques to keep my FPGA designs configurable.

That's fine as far as it goes but doesn't deal with pinout and part type variants.
Pinouts within one device type can sometimes be handled by defining generic node names e.g.pin_1, pin_2 etc. then selectively mapping within the HDL but it's much messier than it could be.
 

[c4757p]

But the constraints file handles pinouts and part type variants! I don't get what the problem is.

[mikeselectricstuff]

But the constraints file handles pinouts and part type variants! I don't get what the problem is.

The problem is that there is no visibility between the constraints file and the HDL, and no way to select a group of constraints (pins in particular) based on a single build option. And no way to select or access the device type.
If, for example there was an IDE/project-generated symbol representing the selected device, visible to both the HDL and constraints, and the constraints file could do #ifdefs or similar based on it, that would be a reasonable solution.

Probably the closest I could get is to turn the whole design into a component and have two projects with different constraints files, and an HDL wrapper that pulls in the same component for the main functionality.

Still way messier than the same process for a microcontroller project, where the C source can look at a processor type variable set by the environment and define pin mappings and functionality based on it.

[c4757p]

I don't know about Lattice, but in both Xilinx and Altera software, you can specify the constraints using TCL (IIRC Altera does this all the time; it's a less common alternative in Xilinx). A TCL constraints file can definitely access all the information you want to make flexible variants, as it's a full script.

Xillinx: UG760, page 26

Altera: Quartus II handbook, vol 2, page 5

[hamster_nz]

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity pin_test is
    Port ( sw : in  STD_LOGIC;
           led : out  STD_LOGIC);
end pin_test;

architecture Behavioral of pin_test is
   attribute LOC : string;
   attribute LOC of sw: signal  is "P114";
   attribute LOC of led: signal is "P123";
begin
   
   led <= sw;

end Behavioral;

Built it, checked it - Q.E.D.

[mikeselectricstuff]

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity pin_test is
    Port ( sw : in  STD_LOGIC;
           led : out  STD_LOGIC);
end pin_test;

architecture Behavioral of pin_test is
   attribute LOC : string;
   attribute LOC of sw: signal  is "P114";
   attribute LOC of led: signal is "P123";
begin
   
   led <= sw;

end Behavioral;

Built it, checked it - Q.E.D.

OK now how do you make the pin assignment conditional on a compile-time constant...?
or, better, stick it in a seperate file, and be able to select one of several files at compile time, preferably depending on the device selected in the project

With #define/#include it would be easy and obvious how to do it.

[Bassman59]

You can do this with VHDL projects as well but you'd have to use a Makefile or similar workflow. The regular FPGA IDEs aren't setup for this.

This is correct.

[nctnico]

But the constraints file handles pinouts and part type variants! I don't get what the problem is.

The problem is that there is no visibility between the constraints file and the HDL, and no way to select a group of constraints (pins in particular) based on a single build option. And no way to select or access the device type.
If, for example there was an IDE/project-generated symbol representing the selected device, visible to both the HDL and constraints, and the constraints file could do #ifdefs or similar based on it, that would be a reasonable solution.

Probably the closest I could get is to turn the whole design into a component and have two projects with different constraints files, and an HDL wrapper that pulls in the same component for the main functionality.

Still way messier than the same process for a microcontroller project, where the C source can look at a processor type variable set by the environment and define pin mappings and functionality based on it.

You can do this with VHDL projects as well but you'd have to use a Makefile or similar workflow. CERN has developed a tool called HDLmake to create an ISE project file based in a Makefile oriented approach. The regular FPGA IDEs aren't setup for this. Either way I see a pin mapping more like a linker description file (which goes at what address) than something that should be included in the HDL. Still you'd need different FPGA bit files for each hardware version.

@Bassman59: had to delete the post you replied to; something went wrong.

[hamster_nz]

Code: [Select]

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity pin_test is
    Port ( sw : in  STD_LOGIC;
           led : out  STD_LOGIC);
end pin_test;

architecture Behavioral of pin_test is
   attribute LOC : string;
   attribute LOC of sw: signal  is "P114";
   attribute LOC of led: signal is "P123";
begin
   
   led <= sw;

end Behavioral;

Built it, checked it - Q.E.D.

OK now how do you make the pin assignment conditional on a compile-time constant...?
or, better, stick it in a seperate file, and be able to select one of several files at compile time, preferably depending on the device selected in the project

With #define/#include it would be easy and obvious how to do it.

It all can be done, just not in a way you are familiar with, or in a way anybody would use it, because it doesn't make sense to do it that way.

It might just be true that 30 years of VHDL engineers missed something as obvious "oh, how about we add #ifdef from C, a language that has been around since 1972". It might also be true that you are used to using that tool and want to use it here even though it isn't really appropriate.

If I had a good understanding of what your needs truly are (i.e. what problem would having #include solve for you), and I can suggest a solution... but it will likely be one or more of the following:

1. Put all your I/O through a single module, and then conditionally use the different modules in your design (VHDL 'GENERATE' clause). This is how you would handle architecture specific features (like PLLs and so on), so if you move to a different architecture you don't have to rework a whole lot of things.

2. Have two different constraints files, and use a script to build the second project. This is how I would handle different PCB layouts for the same chip.

3. Have two different build projects, which share the common source files where appropriate. This is how I would handle building for different vendor's targets (e.g. Altera and Xilinx) where they need different toolchains. (like a cross-compile).

[Bassman59]

But the constraints file handles pinouts and part type variants! I don't get what the problem is.

The problem is that there is no visibility between the constraints file and the HDL

Because the HDL is concerned with the logic description, from a functional point of view. The constraints file controls the implementation.

From a logic perspective, pin assignment is irrelevant, as is pin drive strength, input termination, I/O supply voltage, I/O standard and even clock frequency. Putting all of that stuff into the HDL just clutters the files with stuff that makes the design difficult to port.

Really, I don't see what's so difficult about creating a UCF (if you're a Xilinx non-series-7 user) file for your constraints and being done with it.

and no way to select a group of constraints (pins in particular) based on a single build option. And no way to select or access the device type.

You could use a makefile with the command-line xflow, where you specify all of that stuff.
 
We think that you're making this a lot harder than necessary. It seems to me that you've got one basic hardware design that you use everywhere. As it turns out, most FPGA designs aren't like that. Certainly many logic blocks get reused, but most designs are different enough where that it works best to use a source-code-control system to pull in those resuable logic blocks and the constraints file is created for each specific project.

[mikeselectricstuff]

Really, I don't see what's so difficult about creating a UCF (if you're a Xilinx non-series-7 user) file for your constraints and being done with it.

That is not the problem. The problem is selecting between multiple sets of constraints for one design.
 
 

We think that you're making this a lot harder than necessary. It seems to me that you've got one basic hardware design that you use everywhere. As it turns out, most FPGA designs aren't like that. Certainly many logic blocks get reused, but most designs are different enough where that it works best to use a source-code-control system to pull in those resuable logic blocks and the constraints file is created for each specific project.

What is making things difficult is that FPGA tools use different conventions to software tools, for no other reason than history.
The decreasing cost of FPGAs means it is now routine to use them to augment microcontroler systems, which means the tools would be more productive if similar constructs were available.
Learning tools can be a major part of development time, and where the required functionality isn't that complex,  it can be disproportionate to the design effort.

In terms of how they are designed-in and used, FPGAs really aren't any different to MCUs at the topmost level - they're both chips that need code.
Arbitary and unnecessary differences in how that code is created just get in the way of getting the job done.

I have no illusions that we'll see any improvement any time soon, either from manufacturer or OSS tools. It's just that I get annoyed when things are more difficult than they need to be to get the job done.

Like I said, I only know enough VHDL to get by, as I only use it occasionally, and even then have to look at old designs to remind myself how to do stuff.
With my matrix  LED driver design (which is maybe 50 lines total BTW) , it took about 2 days learning and experimenting to get it paramarised to a useable level to configure display resolutions and data formats, and I have 2 project files for the 2 FPGA types, an copy the VHDL between them whenever I update it, because that's quicker and simpler for that particular situation. Learning how to dick around with makefiles and TCL would not have been a good investment in my time.

If the FPGA tools had, for example,  the same preprocessor functionality as C it would have taken maybe a couple of hours.
On the flipside I now know a lot more VHDL, but I'll probably have forgoten it by the time I do a new FPGA project.    project that happens to have an FPGA hanging on the side of it.

This thread was about how FPGA tools could be made better, albeit via OSS.
All I'm saying is that there are some simple things that could be done to existing tools to make FPGA development more accessible to people familiar with software design flows.

[hamster_nz]

I'm about to have a bit of a rant (not a nasty rant, just a brain dump), so please excuse me....

What is making things difficult is that FPGA tools use different conventions to software tools, for no other reason than history.
...
In terms of how they are designed-in and used, FPGAs really aren't any different to MCUs at the topmost level - they're both chips that need code.
...

But HDL design isn't like software - it might look like software but it isn't A lot of the abstractions that S/W gives you have gone. Lets take the first thing I was told in programming 101 about 30 years ago....

Computers can do three things:

* Sequential execution of sets of instructions
* Conditional execution of sets of instructions
* Iterative execution of sets of instructions (a.k.a. loops)

... and as programmers it is our job to tell the computer what instructions are needed to complete the task. Our example for the day was "instructions for an alien on how to make a cup of tea".

Working on FPGAs in a HDL looks the same (code in a text editor), but it is very different - no longer have:

* sequential execution (as everything occurs in parallel all over the chip)

* the nature of conditional execution changes, because you no longer are executing a series of statements, but configuring a chain of muxes and digital logic.

* Loops do not really exist, unless they are bounded at compile time.

* no fixed data types exist, apart from that binary bits can be treated as numbers

* no dynamic resource allocation is possible - you can't just "malloc" in 64k of SRAM into a design at runtime.

That is a lot of abstractions to loose and on top of that we pick up new problems:

* Timing closure - is everything simple enough to complete in the tick of a clock

* Clock domains and clock domain crossings are just annoying

* Interfacing with FPGA resources

* Fighting against resource limitations - we only have so much chip to use

You can write the instructions for an alien to make a cup of tea in HDL, but it is for an alien with no short term memory. It looks completely different, involving an finite state machine, watching a clock and remembering lots of state information.

And this is why learning HDL is so painful. You hear people say "I've had 20 years of programming, but I find FPGAs hard". This is because

(a) it is complex - implementing an non-trivial high speed digital design is hard work

(b) it is like somebody saying "I've got a degree in literature and used a word processor to write 20 books, yet I find writing a working Arduino program is hard". Of course it is. Although it looks the same it isn't what you are skilled in.

A course in digital logic is more appropriate as a grounding in low-level FPGA work than a course in programming. If you have ever used TTL logic to build a video card, then you would say "My, this FPGA stuff is a walk in the park, it's so fast and flexible, and turnaround time is a few minutes".

With the foundations being so different, it follows that the tools will be different - for example, that is why there is no 'gdb' for VHDL - it is the wrong tool for the job.

[mikeselectricstuff]

I'm about to have a bit of a rant (not a nasty rant, just a brain dump), so please excuse me....

What is making things difficult is that FPGA tools use different conventions to software tools, for no other reason than history.
...
In terms of how they are designed-in and used, FPGAs really aren't any different to MCUs at the topmost level - they're both chips that need code.
...

But HDL design isn't like software - it might look like software but it isn't

I wasn't suggesting otherwise. It has nothing to do with the semantics of the language itself, but the process of managing the deployment of that code to actual devices.
Whilst the meaning of what's written, and the design process is different, the way that coding process fits into the product development process is basically the same - you write code to make the chip do what you want. You use a tool to turn your code into something that the chip can understand.
Like I said, FPGAs and MCUs are both chips that need code.
That code is part of the product. There is no reason that the ways of managing that code at the "preprocessor" and "project" level should be any - it's just an accident of history, but it makes things harder, less consistent and less easy to understand.
Maybe if ADA had won out over C it wouldn't have been so bad...

[Muxr]

To hamster_nz point. I think programmers in general have a hard time with low level programming, since most development happens at a higher level of the stack, and you're encouraged to reuse or leverage other people's low level tools and libs to save time and keep the project scope focused.

But I don't think an HDL is particularly hard. It kind of reminds me of using a coroutine or a green thread framework in networking, except you're very restricted. But then again I have worked with developers who struggle with multithreaded programming. What has helped me I think is that I both have Assembly programming experience as well as writing multithreaded code is what I do at my day job.

I've certainly had a harder time grasping some higher level languages (Haskell) or concepts. At least in an HDL once you get the basic building blocks you can establish a solid fundamental understanding of how everything else is built, because it has to adhere to the basic principles of digital logic which is set in stone (0,1,x,z was a bit weird though), whereas higher level paradigms in your standard programming languages are laced with syntactic sugar and magic that often make little sense.

For instance after knowing Perl and using it, I still come across code I don't understand, whereas only after a few days of learning Verilog I can read other people's code with a fair amount of confidence that I understand what's going on.

I don't think there are as many people who write an HDL or if there are it's not as represented as your [regular] software development. Perhaps because most of it is proprietary (ASIC design) and it's not as open. So that I think is what makes it tougher to get into it since there is less resources to learn from out there.