XXICC (21st Century Co-design) release 0.0r

Its definitely a good idea to produce a language/compiler which feels more comfortable to work with. My recent escapades in Verilog proves so, as a basic example I was using multiple [always @] blocks to perform seperate tasks but later found out that wire/reg types could only be modified in 1[always @]block. This led me to re-writing the entire thing to work around the compilers constraints.

Its only a small issue and I've learnt for the future but a more intelligent compiler would be able to compile my original by automatically combining what I'd written into a single block itself.

Its clear that your software here is going way above and beyond that but it does seem there's a lot of improvements that could and should be made merely as a matter of language/compiler evolution.

Its definitely a good idea to produce a language/compiler which feels more comfortable to work with. My recent escapades in Verilog proves so, as a basic example I was using multiple [always @] blocks to perform seperate tasks but later found out that wire/reg types could only be modified in 1[always @]block. This led me to re-writing the entire thing to work around the compilers constraints.

Its only a small issue and I've learnt for the future but a more intelligent compiler would be able to compile my original by automatically combining what I'd written into a single block itself.

Its clear that your software here is going way above and beyond that but it does seem there's a lot of improvements that could and should be made merely as a matter of language/compiler evolution.

lucie tozer wrote:

 

Its definitely a good idea to produce a language/compiler which feels more comfortable to work with.

Thank you for your comment.  Verilog definitely has some quirks that makes it difficult for the new user.  I've been designing professionally in Verilog for over 10 years and I'm still foggy on the difference between the "=" and "<=" assignments in "always" blocks.  I've worked out my own Verilog subset that synthesizes cleanly, but it's still gnarly.  My approach to Verilog is that I make a mental picture of the hardware I want and then I write the Verilog patterns that fool the synthesizer into doing the right thing... most of the time.  An awkward way to code, but it works and isn't uncommon.

My soapbox speech for the last ten years is that if FPGA vendors had opened up their bitstreams 25 years ago (when I told them they should do it) then FPGAs would be a mainstream technology instead of a niche.  A long form of this speech is in Taming the Wild Bitstream.

The way I've understood the = and the <= thing is that using = means it takes more time before it moves on to the next statement(i.e. waits for the original statement to complete before moving on ie. its a blocking statement so it blocks the flow) whereas if you use a non-blocking <= it takes less time before moving to the next statement but requires more physical logic blocks to do so(its a non-blocking statement so it uses more logic blocks to allow the following statements to be simulated concurrently). It all seems to do with timing and this to me is the only reasoning behind it (but thats coming from a newbie.. theres probably so much I haven't considered).

What do you think are the primary concerns to vendors for opening up their bitstreams? surely if it helps them to sell more of their products it would be worth their while.

lucie tozer wrote:

 

What do you think are the primary concerns to vendors for opening up their bitstreams? surely if it helps them to sell more of their products it would be worth their while.

I'll start by repeating what I said in Taming the Wild Bitstream: "The excuse most commonly heard from FPGA vendors is that they insist their customers want the bitstream format to be secret to prevent reverse-engineering customer designs.  OK, that makes sense except for one thing: millions of uP/uC-based products are designed and sold each year using open CPU architectures, yet there is very little worry that someone is going to reverse-engineer those designs.  IMO most FPGA designers would gladly have better tools in exchange for open bitstream formats.

"Most FPGAs are part of hardware/software systems, and unless the FPGA performs a trivial function, trying to understand what it does and how it interacts with the software is pretty nasty.  Indeed, it'’s hard enough to understand someone else’s FPGA even if you have commented VHDL/Verilog source code :-)  The best you can do is to make an exact copy, which you can do now with the bitstream itself.  Yet people rarely do, because you'’re much better off designing better products with better features than copying your competitor’s last-generation products and trying to modify them enough so that you’re not blatently violating copyright."

I imagine that they have this discussion periodically at FPGA vendors.  I think they fear that they'll lose existing customers if they don't keep the bitstream secret.  One can argue that you could have far more customers -- eventually --- with an open bitstream but mythical future customers have a hard time competing with current real customers.  Plus, there's only a handful of people like me asking for open bitstreams and we don't buy enough chips to show up on the radar.  It's easier just to day "no".

So I am super-grateful to Clifford Wolf and Mathias Lasser for creating IceStorm.  Maybe that will inspire someone to complete Spartan-6 reverse-engineering.  It will probably be someone in Europe -- if you try to do that in the USA you're likely to be sued.

I suspect that the main issues are the real one of support (the FPGA vendor will inevitably end up having to deal with issues with third party tools and lose the ability to tweak the tool set any time there is a hardware issue).

The other issue is the concern of loss of competitive advantage.

I'm much less sure than John that there would be a huge change if third party tool sets were common - there already are third party HDL, simulator and synthesizer tools. Lattice are the best hope for opening up the last step - I think they are quite happy with the ICE situation and watching to see if anything useful comes of it - so far it hasn't (at least as far as I can tell - I haven't looked at the latest XXICC yet).

I'm amused by you both having issues re. Verilog. I have access to fully paid up expensive tools for VHDL and Verilog and the only time I ever do Verilog is when I have to because I need to look at other people's code.

The = <= issue is dealt with so much more nicely in VHDL !

And I like the really pedantic rules - better 10 minutes spent getting it to compile than the 10 days finding the bug.

Like the man said YMMV

MK

lucie tozer wrote:

 

Its definitely a good idea to produce a language/compiler which feels more comfortable to work with. My recent escapades in Verilog proves so, as a basic example I was using multiple [always @] blocks to perform seperate tasks but later found out that wire/reg types could only be modified in 1[always @]block. This led me to re-writing the entire thing to work around the compilers constraints.

Hi Lucie,

I've not actually done much Verilog, but I have done a tonne of VHDL. Designing FPGA based hardware was my job for many years. I think what you are seeing here is because when writing HDL, you need to think about the physical hardware and how what you write will infer different pieces of available hardware and how they are connected rather than thinking of it as just like software where (multi threading aside) everything happens sequentially. If you have the same signal driven out of different registered blocks you are effectively trying to connect the Q output of two or more D types together which you wouldn't try to do if you were wiring physical devices on a breadboard. I think once you get your head round that and try to think a little more about the underlying hardware you are trying to target then it'll all become a lot easier.

Best Regards,

Rachael