[Fpga-synth] Starting points?

[Magnus Danielson]

Theo Verelst skrev:
> On Sat, 2009-03-07 at 01:33 +0100, Magnus Danielson wrote:
>> Dave Manley skrev:
>>> Magnus Danielson wrote:
>>>
>>>> VHDL being an ADA decendent has typing being HARD. This can be a bit 
>>>> annoying for a C programmer like yourself, but eventually you pick up 
>>>> on it.
>>> Not to start a language war, but before choosing between VHDL and 
>>> Verilog, go look at some code in both languages.  As a C programmer, you 
>>> may find Verilog more to your liking.
>> Well, being a C programmer myself before hitting onto HDL of any sort, I 
>> learned VHDL and sticks with it. When I do HDL design work typing it in 
>> VHDL isn't a limiting factor at all really. What is important is to keep 
>> tidy code and know that you get exactly what you want. Looking at 
>> synthesis outputs will eventually be very rewarding as it may trigger 
>> alarm clocks.
>>
>> I think people are making much more fuzz about the VHDL then motivated.
>> But then again, maybe I am biased as I have seen too much poorly formed 
>> Verilog code. Familiar syntax can be a curse rather than a cure.
>>
>> Cheers,
>> Magnus
> 
> 
> As someone who'd built my own logic from electronics even already in the
> 70s it always strikes me that contrary to the well-formed TTL family
> logic for instance, all HDL designs I've witnessed the last years, even
> factory supplied ones (Maybe with the exception of tailored RTL) are
> comparison wise almost extremely under-specified in terms of fundamental
> behavior of parts and connections and timing associated with those, and
> margins and such, so that like with spread out delay and setup and hold
> time and drive line characteristics in TTL, a lot still depends on trial
> and error, preferably with for instance on-fpga probes (like Agilent I
> seem to remember has special interfaces and test software for).

Well, there is a reason for you not seing that. It's all hidden under 
the hood.

To start with, 99,999% of all logic gates and functions sits in a 
synchronous clock domain. You rarely expose things in asynchronous 
fashion except maybe reset, but that is going away too. Under the hood 
the setup and hold times is very well known for all DFFs and all logical 
and interconnections paths. In addition, timing relationships is 
analyzed for min, mean and max temperature and voltage. But all that 
happends under the Place & Route hood and the timing analysis gives you 
an insight at the most critical paths which needs your attention.

Why? Well, the complex of designs today require us to hide away details 
so we can concentrate our efforts on the functional design. If we run 
into timing problems the tools tells us and either we aid the tool or 
re-partion or re-design the system to meet the timing constrains we put 
onto it.

You can still circumvent the rules of these designs, but in the end you 
rarely do it and when you do it is because it is some critical part of 
the design that requires it and is worthy of additional time to achieve 
the performance or peculiar function you need.

> The nice and preferable 'correct by construction' paradigm like in
> Pascal (or C of course, to an extend) seems really not so readily
> achievable, if even at all, which is kind of a shame, I would think.

Again, the size of a typical application has grown immensly since the 
days when Pascal was the big king. Todays OO-rage (which has grown up 
considerably BTW) is to some degree needed. The time when you could sit 
down and think things through properly is to some degree gone. We have 
huge amounts of data, complex software complex that needs to 
interoperate, GUIs, web, levels of security, authorization, monitoring, 
logging, configurations etc. etc. etc.

This comes from a guy that actually makes money by programming in 
assembler as part of the way he works, builds tools in C and make 
designs in VHDL. I don't have to mess with drivers, real time 
schedulings, kernel limitations, databases and gazillions of C/C++ layers.

> The suggestion of 'soled and unbreakable logic', in general, is
> seriously deluding, anyhow, regarding of the HDL language. I even prefer
> schematics from the manufacturer because some of the problems are than
> more over viewable and like the historic logic design process was fairly
> successful, alas lossing portability across brands. Opencores for
> instance does not clearly prove to my anyhow that all the activities of
> those kinds are a huge succes, or at least they are far from insightful,
> and I notice most public shared designs, and I suppose many closed
> source ones, too, are made often for a even a specific target chip.

Schematics can be a useful tool, but none of the FPGA stuff we do have 
them and the gazillions of signals and blocks we have just clutter 
schematics up. For hardware designs even a modest FPGA needs to be 
broken up into pieces since it is too huge to be meaningfully presented 
as a square block. gEDA and gSCHEM had a component design rule which 
said you could only put pins on left or right side... and no power pins. 
Well, I tossed a number of Spartan-IIE symbols on them, each bigger than 
any previous symbols... and soon the symbol generator tools started to 
include the features I used since it was obviously needed. Those chips 
are tiny compared to the Spartan chips of today...

I like and enjoy schematics as the next guy... but for many of the 
designs I see today they would not add significantly to knowledge, block 
level graphics in the design docs does it better.

The type of tools we use change as our designs gets more complex. Things 
which is known to us drops out of fashion and other approaches is used. 
It's not about fashion, its about meeting new challenges. Some of the 
approaches may be popular for some time and then fade, but some is 
meaningful and live on strongly. HDLs like VHDL and Verilog and 
associated friends is mature now and very useful. They solve many but 
not all of our challenges.

Not only designs gets more complex, more people develop them. It is much 
more rarer to see designs where one or very few minds cracks the design 
problems and then completes that vision fully. Infact, they are so 
complex that they are under constant development and changes occurs 
simultanously in different parts of the system. We no longer just use a 
compiler and debugger. We builds ontop of very huge infrastructures at 
many levels.

We also needs to figure out what is the best interface between hardware, 
firmware (FPGA code) and software. The balance can be shifted between 
minor releases now...

There are still more challenges to come, and even more ground-breaking 
changes needs to come.

Just coordinating all these aspects of a modern design effort is a 
hurdle in itself.

My work is actually to sit waaay back and figure out the main aspects of 
designs, scribble things down and help the designers grasp the main 
important things and then let them adjust it as they see fit and help 
them out. I kill design concepts that comes from them with knowledge of 
other aspects they didn't consider. I enjoy a nice quite time in the 
hardware lab or get to get the hands dirty in some debugging session.
Still, there are many aspects of our gear that I haven't the faintest 
idea about and it's fine, I know who to ask to get to the guy that knows...

So in that context, do I enjoy the specs of old TTL chips etc? Yes. Do I 
want to work with that level of details in my day-job? No, for most 
parts it would be such a distraction that it would prohibit efficient 
work. I do dig in to lurk out how I can use some device to its best... 
and take some pride in finding smart and safe ways to do it, but that is 
for the few cases we really, really need it. If we had to do it for 
everything we would loose time we can spend on other things we do get 
paid for. It's wastefull of good hardware, memory and CPU cycle 
resources, but it buys us other freedomes these days.

It's all some kind of part of progress. It's one of these go with the 
flow things. But it is OK to be found mumbling about it here... :)

Cheers,
Magnus