Author Topic: Lattice iCE40 Bitstream Reverse-Engineered  (Read 20672 times)

0 Members and 1 Guest are viewing this topic.

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #50 on: June 03, 2015, 11:27:47 pm »
Not every language has block comments; any editor that isn't incompetent can still comment off a block. You're the first person I've ever seen to claim not having macros makes it archaic, those are archaic features typically only provided by older languages. Async resets are easy to do, I don't know what you're on about there (though I'd not really recommend using them at all). Build variants are easily accomplished using generics.

And  there isn't even a way to have it automatically download to a device on a successful build. or even beep at me to tell me it's done compiling. Pathetic.

buh, wha?? you're using a computer, dude, script it!
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Muxr

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #51 on: June 03, 2015, 11:46:31 pm »
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12099
  • Country: gb
    • Mike's Electric Stuff
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #52 on: June 03, 2015, 11:56:58 pm »
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

Quote
Async resets are easy to do, I don't know what you're on about there
I'm sure they are if you use VHDL regularly. As an occasional user it's the sort of thing I always have to look up, and find the syntax somewhat cumbersome for what should be a simple operation
Quote

 (though I'd not really recommend using them at all).
Power-up initialisation? Dealing with lost input clocks?
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. The FPGA hardware initialises everything to a known state , but by the time the toolchain has had its way it can be anyone's guess what you end up with.
Quote
Build variants are easily accomplished using generics.
Build variants include FPGA type and pinouts. You should be able to specify these in the  HDL.
I have a vague recollection of reading that in ISE there is a way to specify pin constraints in HDL but couldn't find it last time I looked. And even then I don't think this was amenable to selecting with compile-time constants

And  there isn't even a way to have it automatically download to a device on a successful build. or even beep at me to tell me it's done compiling. Pathetic.


buh, wha?? you're using a computer, dude, script it!
This is the sort of stuff that's been standard in MCU environments for ever. FPGA tools are pretty retarded in this sort of useability aspect Again. I shouldn't have to dick around with scripts to get what should be a standard feature of any sane dev environment.

And don't get me started with the ridiculously limited ways to specify ROM data for BlockRAM (in Lattice Diamond at least). On what planet would someone call a "binary" file a text file full of  binary strings...? ...And having to specify ROM data in the native bus width rather than the width you've generated it...
« Last Edit: June 04, 2015, 12:00:09 am by mikeselectricstuff »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #53 on: June 04, 2015, 12:21:49 am »
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?

Quote
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.

Quote
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?
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1292
  • Country: us
  • Yes, I do this for a living
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #54 on: June 04, 2015, 12:28:37 am »
Speaking about VHDL as that's what I sort-of know...
no block comments,

As already noted, that's easily handled by your favorite editor. But it was added to VHDL-2008! It's up to the tool vendors to implement it (as well as other new features).

Quote
no #define,

Why do you need #define? If you want to #define a constant, you can do so either in the architecture's declarative block (before the first begin), or you can pass one through an entity interface as a generic.

You can also create an enumerated type.

If you want to #define a macro, I suppose I should ask: why?

Quote
#include

Why do you need to #include anything? If you wish to "include" a component declaration, you should be using the direct instantiation of an entity idiom instead, such as:

u_foo : entity work.foo port map (bar => bar, bletch => bletch);

This has been in the language since VHDL-93.

If you wish to #include constants, type definitions, function and procedure declarations, use packages, which have been in the language since the beginning.

Quote
compile-time macros

See above.

Quote
Having to hope that the synthesis process infers what you want instead of being able to specify things more simply & directly (e.g. stuff like async resets).

If you code an async reset, you get an async reset. There's no hoping involved. Now, yes, we know that the synthesis tools have a switch which will tell them to convert async resets into sync resets, but that's off by default and of course you are better off coding that sort of thing directly.

Quote
No meaningful way (AFAICS) to easily manage build variants for different parts, pinouts etc. (more of an issue with the whole toolchain than the HDL)

With generics and generate statements you can manage quite a bit. For example, I have this Camera Link transmitter module I wrote initially for Virtex 4, and I ported it to Spartan 6.  what's the difference? XST is too stupid to infer DDR output (and input) flops, so you have to instantiate them. And the library element is not the same for the two families. So a simple generic and generate combo chooses the correct primitive.

As for different pinouts, you are constrained by the family architectures, and which pins support specific features (global clock inputs, differential pairs, hard IP blocks like memory controllers, whatever), and you are correct, that's not really a synthesis issue, more of an implementation-tool issue. So you have to maintain a constraint file with pinouts and timing constraints.

Quote
I'll admit I don't use FPGAs that often and don't know VHDL inside out, but it just seems that I'm often finding that the sort of things that I do routinely in software projects are a total ball-ache to do.

I do FPGAs every day, and I know VHDL as well as anyone who's used it forever can know it, I guess.

I suppose that I can say that I find some of the things one needs to do going between different processors and compilers can be a total ball-ache to do. Oh, this ARM needs this sort of initialization, and code I wrote for my 8051 can't be directly ported to ARM because the 8051 compiler needs to care about different memory spaces where ARM doesn't, and what is this linker-description file stuff, anyway?

Quote
A concrete example - I use Lattice Diamond but my previous experience of ISE seemed pretty much the same.
I have a design that can be used on one of two different PCBs, with a few different FPGAs, depending on pins and memory required for a particular build.
It  already has a lot of paramaterization using VHDL constants ( much of which would have been easier with #ifdef type structures) , but what I'd like to be able to do is have a single #define in the top level source that would allow it to pull in the required set of pin definitions and define the FPGA type depending which PCB it will go on and how big a memory it needs.

Without seeing the design, I really can't suggest better ways of doing what you want. But I do think that setting generics at the top level and making sure the synthesizer can find the correct entity source files and such, you can get there.

What I have done when my (Xilinx) designs need to support different board configurations (depending on the number of ADC channels, etc) is to write the source code to cover the different configurations (again, top-level generics and generate statements as needed), and each configuration has its own .xise and .ucf files. The .xise file has correct settings for the generics which filter down to the source, and the .ucf file has the pinouts defined for each variant. Then of course I have to build each variant, but that's not really a big deal.

Quote
And  there isn't even a way to have it automatically download to a device on a successful build.

Most of the time, I'm not even connected to the real hardware. So that's not very interesting.

Quote
or even beep at me to tell me it's done compiling.

I have the sound turned down on the machine. if everyone's computer beeped every time it did something, there'd be cacophony here. But what I would like to see is an option which will make the entire screen blink brightly and annoyingly so that when the boss walks by, he'll see that the computer is actually doing something and I'm not just just staring into space!
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2222
  • Country: nz
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #55 on: June 04, 2015, 12:31:29 am »
Quote
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.
« Last Edit: June 04, 2015, 12:34:16 am by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1292
  • Country: us
  • Yes, I do this for a living
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #56 on: June 04, 2015, 12:33:16 am »
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.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #57 on: June 04, 2015, 12:36:31 am »
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. >:D

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.)
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1292
  • Country: us
  • Yes, I do this for a living
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #58 on: June 04, 2015, 12:41:09 am »
Quote
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.

Quote
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.
 

Offline Muxr

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #59 on: June 04, 2015, 12:47:45 am »
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.
« Last Edit: June 04, 2015, 12:56:14 am by Muxr »
 

Offline Muxr

  • Super Contributor
  • ***
  • Posts: 1345
  • Country: us
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #60 on: June 04, 2015, 01:19:00 am »
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. >:D

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.
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #61 on: June 04, 2015, 01:38:26 am »
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.)
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline daqq

  • Super Contributor
  • ***
  • Posts: 1729
  • Country: sk
    • My site
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #62 on: June 04, 2015, 05:16:07 am »
Quote
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.
Believe it or not, pointy haired people do exist!
+++Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12099
  • Country: gb
    • Mike's Electric Stuff
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #63 on: June 04, 2015, 07:19:32 am »
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
Quote

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.
Quote
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.

Quote
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.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12099
  • Country: gb
    • Mike's Electric Stuff
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #64 on: June 04, 2015, 07:35:53 am »
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. >:D

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.

 
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18870
  • Country: nl
    • NCT Developments
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #65 on: June 04, 2015, 01:51:19 pm »
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.
« Last Edit: June 04, 2015, 01:54:04 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12099
  • Country: gb
    • Mike's Electric Stuff
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #66 on: June 04, 2015, 06:07:56 pm »
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.
 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #67 on: June 04, 2015, 06:09:31 pm »
But the constraints file handles pinouts and part type variants! I don't get what the problem is.
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12099
  • Country: gb
    • Mike's Electric Stuff
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #68 on: June 04, 2015, 06:49:03 pm »
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.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7805
  • Country: us
  • adieu
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #69 on: June 04, 2015, 06:58:05 pm »
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
No longer active here - try the IRC channel if you just can't be without me :)
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2222
  • Country: nz
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #70 on: June 04, 2015, 07:15:35 pm »
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.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12099
  • Country: gb
    • Mike's Electric Stuff
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #71 on: June 04, 2015, 07:47:07 pm »
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.
« Last Edit: June 04, 2015, 07:55:36 pm by mikeselectricstuff »
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1292
  • Country: us
  • Yes, I do this for a living
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #72 on: June 04, 2015, 08:00:26 pm »
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.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18870
  • Country: nl
    • NCT Developments
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #73 on: June 04, 2015, 08:00:57 pm »
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.
« Last Edit: June 04, 2015, 08:02:39 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2222
  • Country: nz
Re: Lattice iCE40 Bitstream Reverse-Engineered
« Reply #74 on: June 04, 2015, 08:10:33 pm »
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).

Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf