Where is Open Source for FPGA development?

"Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:

> Andy Peters wrote:
>> On Mar 27, 12:06 am, "Daniel S."
>> <digitalmastrmind_no_s...@hotmail.com> wrote:
>>
>>> Back then, I used schematics only to avoid having to code boring top-level
>>> VHDL port maps... but the frequent crashes and other annoyances (like zero
>>> portability) quickly convinced me that I would be better off wrapping
>>> everything up in VHDL.
>>
>> emacs VHDL mode to the rescue.
>>
>> oh, yeah, it's open source.
>
> My primary OS is WinXP... but for all my boring regexable copy-paste
> jobs, I started using remote-X'd Nedit sessions about a year
> ago. Regex replace is definitely a godsend for portmaps and batch
> portmap signal declaration.
>

vhdl-mode is even better, IMHO.  NTEmacs works really well under XP
(it feels a little bit unixy, as all the paths get / in them instead
of \).  There's even a win32 installer now I gather, which sets lots
fo defaults to the way you expect them to work in Windows.

The best bit is the "paste as testbench", which takes your entity and
creates a testbench with all the signals wired up, a clock generator
installed and a process ready for you to fill in.  Now if only it
would do the stimulus and error checking for me :-)

>>> An extra semicolumn at the wrong place can crash XST but these are often
>>> hard to spot since any other programming language would silently accept
>>> them.
>>
>> I take it that you don't simulate much, if at all ...
>>
>> you should have used ModelSim FIRST !
>

In emacs, you can have modelsim compile an individual file at the prod
of a key.  Then you can get a very quick syntax check.

> It depends on what I am doing and why.
>
> Until my larger designs are sufficiently advanced to start producing
> meaningful simulation results (I call this the approximation phase), I
> am more interested in tracking resource utilization and static timing
> evolution than correctness: achieving absolute correctness in the
> first pass (the one most susceptible to typos and syntax errors) is
> useless if the implementation fails to meet target timings or exceeds
> the logic budget. It is during these passes that XST&all die on me the
> most and Modelsim as a simulation tool is irrelevant - that's why it
> took me so long to think of using it as a syntax checker.

But if you make a trivial error in your design, won't the optimiser
chuck lots of stuff out and make it look much better than it is?
You'll never know until you simulate...

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Martin Thompson wrote:
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
> 
>> Until my larger designs are sufficiently advanced to start producing
>> meaningful simulation results (I call this the approximation phase), I
>> am more interested in tracking resource utilization and static timing
>> evolution than correctness: achieving absolute correctness in the
>> first pass (the one most susceptible to typos and syntax errors) is
>> useless if the implementation fails to meet target timings or exceeds
>> the logic budget. It is during these passes that XST&all die on me the
>> most and Modelsim as a simulation tool is irrelevant - that's why it
>> took me so long to think of using it as a syntax checker.
> 
> But if you make a trivial error in your design, won't the optimiser
> chuck lots of stuff out and make it look much better than it is?
> You'll never know until you simulate...

When the optimizer chucks out lots of stuff, it usually spits out 
truckloads of warnings about unconnected signals being trimmed, never 
changing ("replaced by logic") or equivalent to some other net. Some of 
these trimmed signals are expected (is there a simple and inexpensive way 
to quietly drop multiplier LSBs when doing fixed-point maths?) but the rest 
are good indicators of missing stuff.

Since I do not wish to spend much time on control logic during the 
approximation phase, I simply connect the N control signals to an N-bits 
PRNG with a few IOBs blended in to prevent synthesis from simplifying the 
dummy control logic and everything else thereafter. Once the 
data/processing pipeline is in place and looks good, I can start 
implementing and optimizing the real control logic using simulations - I 
usually try to save as much of the control logic as possible for last since 
relatively minor data path refinements can have a major impact on the 
control logic and optimization opportunities... I am lazy so I try to avoid 
moving targets whenever possible.

In news:1175034224.021941.188430@o5g2000hsb.googlegroups.com
timestamped 27 Mar 2007 15:23:44 -0700, "Andy Peters"
<google@latke.net> posted:
"[..]

> An extra semicolumn at the wrong place can crash XST but these are often
> hard to spot since any other programming language would silently accept
> them.

I take it that you don't simulate much, if at all ...

> Over the last two or three years, I wasted over a month hunting down
> syntax-induced crashes, about a week of it last summer because XST got
> confused while processing BRAM inferences... it took me a few days to
> figure out the link between crashes and memory inferences and many more
> tweaking the inference until I got what I wanted without crashing XST or MAP.
>
> The last time I ran into simple syntax errors I was unable to spot within
> 2-3 minutes, I simply ran the thing through ModelSim's compiler... both a
> fair bit faster and much more reliable.

you should have used ModelSim FIRST !"


That is not a good enough excuse.

"Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:

> Martin Thompson wrote:
>> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
>>
>>> Until my larger designs are sufficiently advanced to start producing
>>> meaningful simulation results (I call this the approximation phase), I
>>> am more interested in tracking resource utilization and static timing
>>> evolution than correctness: achieving absolute correctness in the
>>> first pass (the one most susceptible to typos and syntax errors) is
>>> useless if the implementation fails to meet target timings or exceeds
>>> the logic budget. It is during these passes that XST&all die on me the
>>> most and Modelsim as a simulation tool is irrelevant - that's why it
>>> took me so long to think of using it as a syntax checker.
>>
>> But if you make a trivial error in your design, won't the optimiser
>> chuck lots of stuff out and make it look much better than it is?
>> You'll never know until you simulate...
>
> When the optimizer chucks out lots of stuff, it usually spits out
> truckloads of warnings about unconnected signals being trimmed, never
> changing ("replaced by logic") or equivalent to some other net. Some
> of these trimmed signals are expected (is there a simple and
> inexpensive way to quietly drop multiplier LSBs when doing fixed-point
> maths?) but the rest are good indicators of missing stuff.

Yes, I get loads of warnings flagged about dropped bits due to my
tendency to write code that is "easy to reuse 'cos the optimiser will
drop the bits it needs to".  That means important stuff can get lost
in the morass!

>
> Since I do not wish to spend much time on control logic during the
> approximation phase, I simply connect the N control signals to an
> N-bits PRNG with a few IOBs blended in to prevent synthesis from
> simplifying the dummy control logic and everything else
> thereafter. Once the data/processing pipeline is in place and looks
> good, I can start implementing and optimizing the real control logic
> using simulations - I usually try to save as much of the control logic
> as possible for last since relatively minor data path refinements can
> have a major impact on the control logic and optimization
> opportunities... I am lazy so I try to avoid moving targets whenever
> possible.

That must be where we differ then - most of my designs, its the
control logic that takes most of the effort, especially handling error
cases.  The actual "processing" isn't usually my problem...

Now, off to write code which will no doubt prove me wrong within an
hour ;-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Martin Thompson wrote:
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
> 
>> Since I do not wish to spend much time on control logic during the
>> approximation phase, I simply connect the N control signals to an
>> N-bits PRNG with a few IOBs blended in to prevent synthesis from
>> simplifying the dummy control logic and everything else
>> thereafter. Once the data/processing pipeline is in place and looks
>> good, I can start implementing and optimizing the real control logic
>> using simulations - I usually try to save as much of the control logic
>> as possible for last since relatively minor data path refinements can
>> have a major impact on the control logic and optimization
>> opportunities... I am lazy so I try to avoid moving targets whenever
>> possible.
> 
> That must be where we differ then - most of my designs, its the
> control logic that takes most of the effort, especially handling error
> cases.  The actual "processing" isn't usually my problem...

Re-read my paragraph... I think you misread it: I fully agree that control 
logic is indeed the most complicated part of most designs. What I said is 
that I keep control for late/last to avoid having to recode it should any 
significant alterations in the pipeline become necessary due to 
timing/area/other constraints.

> Now, off to write code which will no doubt prove me wrong within an
> hour ;-)

"Hey Martin, there's a new feature we added to the specs... you will have 
six more control bits and two extra pipeline stages to manage. 
Unfortunately for you, the extra stages and controls sit smack in the 
middle of the two spots that gave you so many headaches over the last week 
or two."

Of course, waiting until the data path is completed only reduces the 
likelihood of late changes ruining control efforts, it does not immunize 
against late changes... and it still requires a "disposable" (minimum 
effort) controller for preliminary data path testing.

"Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:

> Martin Thompson wrote:
>> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
>>
>>> Since I do not wish to spend much time on control logic during the
>>> approximation phase, I simply connect the N control signals to an
>>> N-bits PRNG with a few IOBs blended in to prevent synthesis from
>>> simplifying the dummy control logic and everything else
>>> thereafter. Once the data/processing pipeline is in place and looks
>>> good, I can start implementing and optimizing the real control logic
>>> using simulations - I usually try to save as much of the control logic
>>> as possible for last since relatively minor data path refinements can
>>> have a major impact on the control logic and optimization
>>> opportunities... I am lazy so I try to avoid moving targets whenever
>>> possible.
>>
>> That must be where we differ then - most of my designs, its the
>> control logic that takes most of the effort, especially handling error
>> cases.  The actual "processing" isn't usually my problem...
>
> Re-read my paragraph... I think you misread it: I fully agree that
> control logic is indeed the most complicated part of most
> designs. What I said is that I keep control for late/last to avoid
> having to recode it should any significant alterations in the pipeline
> become necessary due to timing/area/other constraints.
>

OK, fair enough - I understand where you're coming from.

>> Now, off to write code which will no doubt prove me wrong within an
>> hour ;-)
>
> "Hey Martin, there's a new feature we added to the specs... you will
> have six more control bits and two extra pipeline stages to
> manage. Unfortunately for you, the extra stages and controls sit smack
> in the middle of the two spots that gave you so many headaches over
> the last week or two."

That's be the difference then - most of my current FPGA is explicitly not
data-path, so there are very few changes to the data-path that are
likely to cause me headaches :-)  I hope...

>
> Of course, waiting until the data path is completed only reduces the
> likelihood of late changes ruining control efforts, it does not
> immunize against late changes... and it still requires a "disposable"
> (minimum effort) controller for preliminary data path testing.

Indeed.  How about we disallow late changes :-)  That's go down well!

Cheers,
Martin



-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Martin Thompson wrote:
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
> 
>> "Hey Martin, there's a new feature we added to the specs... you will
>> have six more control bits and two extra pipeline stages to
>> manage. Unfortunately for you, the extra stages and controls sit smack
>> in the middle of the two spots that gave you so many headaches over
>> the last week or two."
> 
> That's be the difference then - most of my current FPGA is explicitly not
> data-path, so there are very few changes to the data-path that are
> likely to cause me headaches :-)  I hope...
> 
>> Of course, waiting until the data path is completed only reduces the
>> likelihood of late changes ruining control efforts, it does not
>> immunize against late changes... and it still requires a "disposable"
>> (minimum effort) controller for preliminary data path testing.
> 
> Indeed.  How about we disallow late changes :-)  That's go down well!

Architecture/Feature freezes are usually a good thing... but changes can 
still be forced by external factors: peripheral chips can go obsolete, 
better options (updated parts, pricing changes, etc.) can come along, 
provisioning/IP contracts can fall through, FPGA sizing guesstimates can 
come out too tight or short, etc.

I worked for a couple of post-docs on a software-defined radio project some 
years ago. They had XC2V4000 devices they thought would be sufficient for 
their design but they found out, about a year into the design phase, that 
even the TX pipeline would (barely) not fit on a single FPGA and they ended 
up halving their design goals to give the RX side a decent chance of 
fitting in its own 2V4000. About a year after my contract ended, one of 
them showed me one of the first commercial derivatives from this research 
project which ended up halved a second time to make everything (RX + TX + 
some previously external bits like CPU/PPC405 and SERDES/MGT) fit in a 
single XC2VP70. Today, I suspect they would be easily able to pull off the 
initial specs with a single XC5VSX95T, assuming they would not mind going 
back to off-chip CPUs. I remember the docs being really &%#%@'d about the 
largest 4VSX being undersized logic-wise, having such a ridiculous 
logic-to-DSP48 ratio and no PPC/MGT while even the largest devices in the 
4VFX family had way too few DSP48s, rendering both families completely 
useless for their application. I am certain these folks would be really 
happy if Xilinx decided to include a SINGLE (and no more than one) PPC405 
core in all LX/SX FPGAs... an XC5VSX95T with an on-chip PPC405 would be a 
dream platform for them: excellent logic-to-DSP48 ratio for their 
application, a couple of MGTs and one PPC405 in one package to reduce 
external parts count.

When dealing with bleeding-edge projects, tables can turn in any direction 
at any time for all sorts of reasons. The docs planned their design with 
hopes that the V4 would meet their needs by providing resource balance 
similar to the V2P but the preliminary V4 specs they received thoroughly 
terminated all such expectations.

You get to see lots of interesting things when riding with people who are 
at the edge of their respective domains.

"Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:

> Martin Thompson wrote:
>> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
>>
>>> "Hey Martin, there's a new feature we added to the specs... you will
>>> have six more control bits and two extra pipeline stages to
>>> manage. Unfortunately for you, the extra stages and controls sit smack
>>> in the middle of the two spots that gave you so many headaches over
>>> the last week or two."
>>
>> That's be the difference then - most of my current FPGA is explicitly not
>> data-path, so there are very few changes to the data-path that are
>> likely to cause me headaches :-)  I hope...
>>
>>> Of course, waiting until the data path is completed only reduces the
>>> likelihood of late changes ruining control efforts, it does not
>>> immunize against late changes... and it still requires a "disposable"
>>> (minimum effort) controller for preliminary data path testing.
>>
>> Indeed.  How about we disallow late changes :-)  That's go down well!
>

<snip good story>

> I am certain these
> folks would be really happy if Xilinx decided to include a SINGLE (and
> no more than one) PPC405 core in all LX/SX FPGAs... an XC5VSX95T with
> an on-chip PPC405 would be a dream platform for them: excellent
> logic-to-DSP48 ratio for their application, a couple of MGTs and one
> PPC405 in one package to reduce external parts count.
>

Yes, I found it weird that one PPC wasn't in *all* the families.

> You get to see lots of interesting things when riding with people who
> are at the edge of their respective domains.

Indeed!

Cheers,
Martin


-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Hey Kolja,

On 26 Mrz., 12:14, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
> Matlab. Antoher one is a recent paper on a GI workshop that show how
> easy it is to extend the synthesizable
> subset of VHDL. They presented a VHDL to VHDL preprocessor that
> allowed you to use more constructs in your
> synthesizable code than Synopsys supports. Yet another example are
> timing diagram editors for documentation.

Can you point me to that paper? If "GI" stands for the german
"Gesellschaft f=FCr Informatik", then I am a member and have missed the
paper anyway ;-)

Thanks, Torsten

On Apr 3, 9:04 am, "Torsten Landschoff" <t.landsch...@gmx.de> wrote:
> Hey Kolja,
>
It was at "7. GI/ITG/GMM-Workshop Modellierung und Verifikation". I
just picked up the proceedings and was looking for the paper and
realised, that there were multiple papers that were trying to extend
the synthesizable part of the language.

The Paper that I had in mind used XSLT to transform VHDL to VHDL:
* Oetjens, Gerlach, Rosenstiel: "Ein XML-basierter Ansatz zur
flexiblen Darstellung und Transformation von Schaltungsbeschreibungen"

Than there was another paper about a more special case:
* Jan Gutsche, H.-U. Post: "Erh=F6hung der Synthesegenauigkeit durch
Sprachraumerweiterung synthesef=E4higer sequentieller VHDL-
Beschreibungen".

Less practical but especially enlightening was this paper:
 * Meinrad Fiedler: "Ein =DCbersetzungsverfahren von Verilog-
Kausalspezifikationen in Signalflankengraph-basierte Spezifikationen
zum Entwurf asynchroner Schaltwerke".
What the author is presenting as a simple example does not look
remotely similar to anything that could be synthesized using Synopsys
DC.
This shows that what is to be considered "synthesizable" is largely in
the eye of the beholder.

always
 begin
  @(posedge c);
  if (s)
   begin
    y =3D 1;
    @(negedge c);
    y =3D 0;
   end
  else
   begin
     z=3D1;
     @(negedge c);
     z=3D0;
   end
  end

> On 26 Mrz., 12:14, "comp.arch.fpga" <ksuli...@googlemail.com> wrote:
>
> > Matlab. Antoher one is a recent paper on a GI workshop that show how
> > easy it is to extend the synthesizable
> > subset of VHDL. They presented a VHDL to VHDL preprocessor that
> > allowed you to use more constructs in your
> > synthesizable code than Synopsys supports. Yet another example are
> > timing diagram editors for documentation.
>
> Can you point me to that paper? If "GI" stands for the german
> "Gesellschaft f=FCr Informatik", then I am a member and have missed the
> paper anyway ;-)
>
> Thanks, Torsten