Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 31700

Article: 31700
Subject: Re: one state machine
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Sun, 03 Jun 2001 13:16:46 GMT
Links: << >>  << T >>  << A >>
> i can't find the clue on how to solve optimally this problem in
> vhdl,(or verilog), any help please!!!
> i want to design an irregular counter
> say acound modulo 8 but with these outputs
> [4,7,2,3,0,1,6,5]
>
> someone suggests me to design a counter and later add such similair
> code
> CASE counter IS
>     WHEN 0 => output <= 4;
>     WHEN 1 => output <= 7;
> .....
>
> i expect that the synthesizer will do it in 2 logic levels, whereas
> one logic level is feasible ?
>
> thanks

     If the  CASE statement above results in a registered "output," then the
logic levels are divided such that you only get "1" logic level for the
counter and "1" logic level for the case statement.  If you can stand the
one clock latency for "output," then there is nothing wrong with above
method.
     On the other hand, why not just use the CASE statement above to
directly implement your irregular "counter?"  It wouldn't be a real counter
in the true sense of the word, but it would implement the irregular count
that you are looking for.
Simon Ramirez, Consultant
Synchronous Design,  Inc.
Oviedo, FL  USA



Article: 31701
Subject: Re: Xilinx webpack and modelsim
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Mon, 04 Jun 2001 00:23:04 +1000
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
[snip]
> > > If you do a back annotated simulation, you do not have to run
> > > this as a timed simulation, you can still do it as unit delay.
> >
> > Yes, this is the way I normally do them.  I'm a big believer in
> > functional simulation and static timing analysis.
> 
> Er, then what's the fuss?
> 
> >  (Although care is
> > needed to ensure the correctness of multicycle paths.)
> 
> Why?

Hi Austin,

The problem with multicycle paths is that it is possible to get the
specification wrong.  E.g. you tell the tools that a particular path can
take n clocks to complete, but the design actually requires n - 1
clocks.
This can happen because the multicycle path information is hidden in the
UCF along with the other time specs, so if a third party modifies the
VHDL source, they may not be aware that a multicycle path exists (even
if the comments in the code say there is one).

The problem with verification of multicycle paths is that the functional
/ unit delay simulation won't model the multicycle nature of the delay.

My preferred way to work around the problem (apart from avoiding
multicycle paths unless I really need them) is to model the delay in the
VHDL source.

This is a model of the system with a 5 ns clock and a two cycle path:

sig1 <= sig2;

This clearly behaves differently in simulation and synthesis.

If I add a delay clause, it models the multicycle delay in functional
simulation.

sig1 <= sig2 after 8 ns;

The synthesiser will ignore the after 8 ns part.  The 8ns is arbitrary,
but it must be greater than the clock period, but less than twice the
clock period minus the (simulated) delay of any other blocks in the
path.
If the design can't tolerate the delay here, I will now find out in
simulation, rather than in the lab.

I like this.  It seems to work with most tools (Synplify is fine, and
Leonardo would give a warning that it was ignoring the after clause, but
it had no ill effects), and produces the same results in both simulation
and synthesis - something I consider very important for verification.

It's still possible to get a mismatch between the UCF and the VHDL
source, but at least this way it's easy to identify all the intended
multicycle paths, by grepping for "after" in the source code.

> > I should point out that I don't normally do gate level
> > simulation, except when I suspect that there is a tool
> > problem.
> 
> I have not run into the problems you cited, but I don't use
> VHDL...ever think that might be the problem ;-)

Good point.  Most of the "serious" bugs (i.e. the ones where the tools
silently generate the wrong result) do seem to be in the front end (VHDL
compilers).
I see plenty of back end bugs, but these seem to be mostly things like
crashes, where you know something has gone wrong.
I've also seen speed file errors, but I'm not sure we can classify these
as back end bugs.
 
Regards,
Allan.

Article: 31702
Subject: Re: one state machine
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Sun, 03 Jun 2001 17:10:00 GMT
Links: << >>  << T >>  << A >>
If you are using Xilinx, this is a great application for the SRLs.  You
could use three SRLs, which are 16-bit shift registers, to output any
aribratry repeating sequence of a three-bit number with a repeat rate of up
to 16.  You make them into rings by tying the output of the SRL to the
input.  If you want a repeat rate of 8, you set the SRL address lines to 7.
This would all take less than one CLB, including the register flops.  You
just have to initially program the SRLs with the sequence you desire.

Also, if you do it as you described below, you wouldn't need two logic
levels.  Just make sure the signal "counter" is a registered value (i.e.
pipelined) and then you will only have one logic level between flops.

-Kevin

"finish" <finishf@yahoo.com> wrote in message
news:45137d06.0106030437.1646cb35@posting.google.com...
> hello,
>
> i can't find the clue on how to solve optimally this problem in
> vhdl,(or verilog), any help please!!!
> i want to design an irregular counter
> say acound modulo 8 but with these outputs
> [4,7,2,3,0,1,6,5]
>
> someone suggests me to design a counter and later add such similair
> code
> CASE counter IS
>     WHEN 0 => output <= 4;
>     WHEN 1 => output <= 7;
> .....
>
> i expect that the synthesizer will do it in 2 logic levels, whereas
> one logic level is feasible ?
>
> thanks
>



Article: 31703
Subject: Re: XtremeDSP Ready for prime time?
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Sun, 03 Jun 2001 17:35:01 GMT
Links: << >>  << T >>  << A >>
I have had experience integrating code generated by the Cadence SPW tool.  I
think it is very similar to System Generator; one draws block diagrams of a
DSP system and the tool generates Verilog.  I think the most of the problems
I had would be the same for the whole family of tools.

The tools work very well in terms of making a DSP design easier and perhaps
more intuitive.  However problems crop up on the leading edge.  Analagous is
how a compiler makes software design much easier but loses out to assembly
in very critical applications.

If you can meet timing, everything is fine.  But in one case, I couldn't
meet timing with the generated code.  It was necessary to use several
tricks, like duplicating logic similar to Shannon expansion and manually
reducing fanout on critical nets.  The high-level tools don't deal with
these low-level problems.  Therefore I had to manually edit the code.  This
was a huge task, because the source generated is functionally but nearly
unintelligible, with netnames such as n_98742 and every register set buried
in its own module.  Again, it was like editing assembly generated by a C
compiler.  Also, there are tricks such as using a single BRAM as two
indpendent ROMs (saving half your BRAMs) which I don't think the generation
tools can deal with.  In this case, I may have saved a lot of time by
writing all the source instead of using code generated by the tool.  What I
am left with is a bunch of unreadable hacked code, which cannot be modified
by anyone else (nor myself), nor can the tool be used to tweak any
parameters, because generating source from the tool again would not include
my hacks.

In summary, I believe these tools may save time, but only when there is
plenty of margin to deal with.

-Kevin

"cybin" <cybin@home.com> wrote in message news:3B19B9EE.56137102@home.com...
> I've been using system Generator for three months since it's release and
> have found somewhat erratic performance. I would be interested in
> sharing my experience with other System Generator users in hopes of
> finding and sharing solutions that would be of benefit to all. Perhaps a
> data base could be constructed outside the Xilinx infrastructure for
> this purpose.
>
> Regards,
>



Article: 31704
Subject: Pentium 4 or AMD ?
From: "Domagoj" <domagojtake_this_out@rasip.fer.hr>
Date: Sun, 3 Jun 2001 19:49:18 +0200
Links: << >>  << T >>  << A >>
Hi!

 Has anybody done any comparison of
Pentium 4 vs. AMD architectures for PAR and
simulation ? What about RIMM/DRAM/DDR ?

thx

Regards,
     Domagoj Babic
   domagoj(et)rasip.fer.hr



Article: 31705
Subject: Re: pci pads
From: "Tom Verbeure" <tverbeure@globespan.net>
Date: Sun, 3 Jun 2001 13:54:11 -0400
Links: << >>  << T >>  << A >>
You should use the bidir PCI IO pads. PCI IO pads have special requirements
wrt protection against heavy overshoot by adding clamping against special
voltage rails.
This is probably not an issue for RST# (since this is mosty a static
signal).
As for IDSEL, it is not uncommon to connect this signal to one of the PAD
signals (eg. IDSEL of slot 0 to PAD16, IDSEL of slot 1 to PAD17 etc), so
there you certainly have to use PCI pads.

Tom

> But I don't know if I can use the PCI bidirectional pad for input only
pins
> like CLK, RST#, IDSEL, and GNT#(in case of a non-arbiter device.)
> In my opinion, normal CMOS pads (non-PCI) should be used for CLK, RST#,
and
> IDSEL because they are usually from system, not from PCI bus. GNT# also
> often comes from non PCI device.
> Am I right?




Article: 31706
Subject: ASIC-FPGA job in USA
From: stchannel@aol.com (Stece Lutz)
Date: 03 Jun 2001 19:59:42 GMT
Links: << >>  << T >>  << A >>
"ACD is looking for ASIC/FPGA design engineers for USA.
Minimum 5 yrs. experience needed.
H1B visa provided within 2 weeks (new law !!!!)
Send resume to:
resume@acdcon.com"

Greg Miller
US-California

Article: 31707
Subject: Re: one state machine
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Sun, 03 Jun 2001 14:06:15 -0700
Links: << >>  << T >>  << A >>
This is trivial.
Since FPGAs use 4-input look-up tables, you can design any arbitrary 4-bit
counter sequence in just 4 look-up tables.
In your case, you need only 3 LUTs.
Just write down the logic equations for the three D-inputs.
Hint: In your case, D0 just toggles, so feed ot with Q0bar.
It should take you less than 15 minutes to write the three logic equations, then
leave it to the synthesis tool to optimize it down to  a single level of logic.

Peter Alfke, Xilinx Applications
=======================
finish wrote:

> hello,
>
> i can't find the clue on how to solve optimally this problem in
> vhdl,(or verilog), any help please!!!
> i want to design an irregular counter
> say acound modulo 8 but with these outputs
> [4,7,2,3,0,1,6,5]
>
> someone suggests me to design a counter and later add such similair
> code
> CASE counter IS
>     WHEN 0 => output <= 4;
>     WHEN 1 => output <= 7;
> .....
>
> i expect that the synthesizer will do it in 2 logic levels, whereas
> one logic level is feasible ?
>
> thanks


Article: 31708
(removed)


Article: 31709
Subject: Re: one state machine
From: Kolja Sulimma <kolja@sulimma.de>
Date: Mon, 04 Jun 2001 01:36:57 +0200
Links: << >>  << T >>  << A >>
Peter is right, but something like:

CASE output IS
    WHEN 4 => output <= 7;
    WHEN 7 => output <= 2;
....

should be more readable and obtain the same results.

Your example would need two levels of logic because there is logic in the feedback
path and logic between the flip-flops and the outputs. I would not expect the tools
to optimize across Flip-Flops.
(Both area optimal  retiming and state encoding algorithms are not very wide spread
among FPGA tools)

Kolja Sulimma

Peter Alfke wrote:

> This is trivial.
> Since FPGAs use 4-input look-up tables, you can design any arbitrary 4-bit
> counter sequence in just 4 look-up tables.
> In your case, you need only 3 LUTs.
> Just write down the logic equations for the three D-inputs.
> Hint: In your case, D0 just toggles, so feed ot with Q0bar.
> It should take you less than 15 minutes to write the three logic equations, then
> leave it to the synthesis tool to optimize it down to  a single level of logic.
>
> Peter Alfke, Xilinx Applications
> =======================
> finish wrote:
>
> > hello,
> >
> > i can't find the clue on how to solve optimally this problem in
> > vhdl,(or verilog), any help please!!!
> > i want to design an irregular counter
> > say acound modulo 8 but with these outputs
> > [4,7,2,3,0,1,6,5]
> >
> > someone suggests me to design a counter and later add such similair
> > code
> > CASE counter IS
> >     WHEN 0 => output <= 4;
> >     WHEN 1 => output <= 7;
> > .....
> >
> > i expect that the synthesizer will do it in 2 logic levels, whereas
> > one logic level is feasible ?
> >
> > thanks


Article: 31710
Subject: Looking for free (try) xc4000e software ?
From: "Wisut Hantanong" <systemdesign@engineer.com>
Date: Sun, 3 Jun 2001 17:13:14 -0700
Links: << >>  << T >>  << A >>
I mean of  pub license like some linux software or demo or shareware.

thank you.



Article: 31711
(removed)


Article: 31712
Subject: does anyone have a disassembler for a 18P8 PAL?
From: jonwil@tpgi.com.au (Jonathan Wilson)
Date: 3 Jun 2001 22:50:56 -0700
Links: << >>  << T >>  << A >>
does anyone have a disassembler for a 18P8 PAL?
I need

Article: 31713
Subject: Re: one state machine
From: Allan Herriman <allan_herriman.hates.spam@agilent.com>
Date: Mon, 04 Jun 2001 21:02:22 +1000
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> This is trivial.
> Since FPGAs use 4-input look-up tables, you can design any arbitrary 4-bit
> counter sequence in just 4 look-up tables.
> In your case, you need only 3 LUTs.
> Just write down the logic equations for the three D-inputs.
> Hint: In your case, D0 just toggles, so feed ot with Q0bar.
> It should take you less than 15 minutes to write the three logic equations, then
> leave it to the synthesis tool to optimize it down to  a single level of logic.

I know it's "trivial" but I found it quite hard to get the best results
from a particular VHDL synthesiser (Synplify) when I tested this.

The best way to express it in VHDL seems to be to use a constant array
to specify the state transitions
... 
  constant num_counts : integer := 8;

  type count_array is array (0 to num_counts - 1) of integer;

  constant next_count : count_array := (
    1,6,3,0,7,4,5,2
  );

  signal count : integer range 0 to num_counts - 1;

begin

counter : process (clock)
begin
  if (rising_edge(clock)) then
    count <= next_count(count);
  end if;
end process counter;
...

Suprisingly, Synplify decided that this was best implemented as a
one-hot, and used 6 flip flops and 3 LUTs.

Recoding as:

  case count is
    when 0 => count <= 1;
    when 1 => count <= 6;
    when 2 => count <= 3;
    when 3 => count <= 0;
    when 4 => count <= 7;
    when 5 => count <= 4;
    when 6 => count <= 5;
    when 7 => count <= 2;
    when others =>
  end case;

... gave identical results i.e. 6 flip flops and 3 LUTs.

I didn't get the optimal answer (3 FF, 3 LUT, 300MHz) until I switched
to Synplify Pro to use "FSM Explorer".  It tries different FSM encodings
to find the best one.  It takes a while, too (about 4 seconds for this
tiny design).

Sometimes, schematics seem just so much easier.  I really hate it when
the language and tools get in the way of getting the job done.

I'd be interested in seeing the results from other VHDL synthesisers. 
(Complete source code available via email.  Remove the ".hates.spam" bit
from my address first.)

Regards,
Allan.

 
> Peter Alfke, Xilinx Applications
> =======================
> finish wrote:
> 
> > hello,
> >
> > i can't find the clue on how to solve optimally this problem in
> > vhdl,(or verilog), any help please!!!
> > i want to design an irregular counter
> > say acound modulo 8 but with these outputs
> > [4,7,2,3,0,1,6,5]
> >
> > someone suggests me to design a counter and later add such similair
> > code
> > CASE counter IS
> >     WHEN 0 => output <= 4;
> >     WHEN 1 => output <= 7;
> > .....
> >
> > i expect that the synthesizer will do it in 2 logic levels, whereas
> > one logic level is feasible ?
> >
> > thanks

Article: 31714
Subject: Virtex LUT4 problems in FPGA Express
From: Michael Dales <michael@dcs.gla.ac.uk>
Date: 04 Jun 2001 12:37:22 +0100
Links: << >>  << T >>  << A >>
Hi there,

I'm trying to implement an algorithm using the LUT4 on Virtex. I have
numerous variations on the following:

 lut_0:  LUT4 generic map (INIT => X"0E6E")
   port map (res(0), val(0), val(1), val(2), val(3));

This simulated fine using the Alliance libraries compiled for Cadence
Leapfrog, but when I tried to run it through FPGA Express it barfs on
my generic map, with the following error:

"Bad formal part - port names in entity and component declarations do
not match."

I checked the unisim vcomponents file and the component declaration
seems to be correct.

Any suggestions?

-- 
Michael Dales --- email: michael@dcs.gla.ac.uk --- tel: +44 141 330 6297
Department of Computing Science, University of Glasgow, Glasgow, G12 8QQ

Article: 31715
Subject: Re: one state machine
From: finishf@yahoo.com (finish)
Date: 4 Jun 2001 05:31:38 -0700
Links: << >>  << T >>  << A >>
hi,

may be i was not so clear. what i asked should be done ( and i have
done it) in one level logic.
i wanted to know can i save my 15 mn as you said by expressing that in
vhdl, without giving the LUT formaulas ?
it looks that the synthesiser fails to do it in one level logic
and as i am weak in vhdl( i don't use it as input), i wanted a hint

regards
Peter Alfke <peter.alfke@xilinx.com> wrote in message news:<3B1AA6C7.B513E2A0@xilinx.com>...
> This is trivial.
> Since FPGAs use 4-input look-up tables, you can design any arbitrary 4-bit
> counter sequence in just 4 look-up tables.
> In your case, you need only 3 LUTs.
> Just write down the logic equations for the three D-inputs.
> Hint: In your case, D0 just toggles, so feed ot with Q0bar.
> It should take you less than 15 minutes to write the three logic equations, then
> leave it to the synthesis tool to optimize it down to  a single level of logic.
> 
> Peter Alfke, Xilinx Applications
> =======================
> finish wrote:
> 
> > hello,
> >
> > i can't find the clue on how to solve optimally this problem in
> > vhdl,(or verilog), any help please!!!
> > i want to design an irregular counter
> > say acound modulo 8 but with these outputs
> > [4,7,2,3,0,1,6,5]
> >
> > someone suggests me to design a counter and later add such similair
> > code
> > CASE counter IS
> >     WHEN 0 => output <= 4;
> >     WHEN 1 => output <= 7;
> > .....
> >
> > i expect that the synthesizer will do it in 2 logic levels, whereas
> > one logic level is feasible ?
> >
> > thanks

Article: 31716
Subject: Re: one state machine
From: Kolja Sulimma <kolja@sulimma.de>
Date: Mon, 04 Jun 2001 16:16:24 +0200
Links: << >>  << T >>  << A >>


finish wrote:

> hi,
>
> may be i was not so clear. what i asked should be done ( and i have
> done it) in one level logic.
> i wanted to know can i save my 15 mn as you said by expressing that in
> vhdl, without giving the LUT formaulas ?
> it looks that the synthesiser fails to do it in one level logic
> and as i am weak in vhdl( i don't use it as input), i wanted a hint

Did you read my posting from 1:36 today?
It should answer your request.

Kolja Sulimma


Article: 31717
Subject: Re: Virtex LUT4 problems in FPGA Express
From: Michael Dales <michael@dcs.gla.ac.uk>
Date: 04 Jun 2001 16:29:26 +0100
Links: << >>  << T >>  << A >>

Cheers for the reply. The component declaration was a standard one,
found in Fndtn\vhdl\src\unisims\unisim_VCOMP.vhd in Foundation. 

The problem seems to be more to do with my lack of experience than
anything else. I eventually noticed that the unisim file tells
synopsis to ignore the generic map for some reason. Armed with this
info and a hunt around the Xilinx answer database seemed to suggest
that I manually include the following component declaration:

  component LUT4
    generic (INIT : bit_vector := X"0000");
    port (
      O                              :  out   STD_ULOGIC;
      I0                             :  in    STD_ULOGIC;
      I1                             :  in    STD_ULOGIC;
      I2                             :  in    STD_ULOGIC;
      I3                             :  in    STD_ULOGIC);
  end component;
  
This seems to have enabled me to compile the circuit, though I've not
had time to test it for functional correctness to see if indeed my
INIT parameter made it thru to the end result.

-- 
Michael Dales --- email: michael@dcs.gla.ac.uk --- tel: +44 141 330 6297
Department of Computing Science, University of Glasgow, Glasgow, G12 8QQ

Article: 31718
Subject: Re: Pentium 4 or AMD ?
From: Eric <erv@sympatico.ca>
Date: Mon, 04 Jun 2001 11:33:39 -0400
Links: << >>  << T >>  << A >>
I would go with AMD Athlon 1333 with DDR memory.

P4 reaches 1.7Gigs but to achieve this, the pipeline
is much too long, a typical case of marketing tactics
interfering badly with real word performance.

Also, P4 only works with infamous RDRAM (RIMM)
that underperforms and costs too much (especially since
large Xilinx devices PAR requires anywhere between 256M
and 1Gig RAM). Main technical problem with RDRAM
is the very long latency time, compared to SDRAM / DDR
that is not compensated by the higher theoretical peak
bandwidth.

If you want to get the most of your system, use DDR
from major brands (Micron) that's specified with a CAS
latency of 2 or 2.5.

Here is a good memory module vendor :
http://www.corsairmicro.com/main/products.htm

Some multimedia benchmarks show P4 performing better
than AMD Athlon, because those applications use the P4
proprietary SSE2 extended instructions. AFAIK, PAR does
not use them, so these benchmarks can safely be ignored.

You can find lots of benchmarks here as long as you forget
about the gaming/overclocking stuff :

Intel P4 1.7Gigs
http://www6.tomshardware.com/cpu/01q2/010423/index.html

AMD Athlon 1333 / DDR
http://www6.tomshardware.com/cpu/01q1/010322/index.html

----------

One thing I always wondered is the reason why the PAR
software can't use FPGA based hardware accelerators.
Maybe the PAR algorithms are not a good fit for FPGA
processing, or market for such devices would be too small ?

----------

Eric.

-----------------------------------------------------


Domagoj wrote:

> Hi!
>
>  Has anybody done any comparison of
> Pentium 4 vs. AMD architectures for PAR and
> simulation ? What about RIMM/DRAM/DDR ?
>
> thx
>
> Regards,
>      Domagoj Babic
>    domagoj(et)rasip.fer.hr


Article: 31719
Subject: Re: XtremeDSP - the dawn of a new age
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 04 Jun 2001 08:34:50 -0700
Links: << >>  << T >>  << A >>
Kevin,

Your allusion to early compilers is accurate.

Initially, examining early compiler output, I saw how I could have done a much
better job of coding (yes, I was a programmer for eleven years once upon a time
for real time telephone switching equipment).

After awhile, the compilers got better and I was less often able to improve upon
a function.

Eventually, I gave up trying.  I would occasionally have to code the interrupt
handlers and parts of the RTOS by hand in assembly to make sure I met my timing.

With the DSP in FPGAs we are facing a similar situation:  the tools are in their
infancy (although some like Berkeley's Ptolemey are almost eight years old now).

My suggestion is to use the tools on small blocks (those that can not be
purchased outright as cores or IP ... why spin your own if there are suitable
ones available for less money than it will take to do your own?).

Examine the resultant verilog, and synthesized logic for the block functions.
Optimize the blocks that need to be optimized.  Comment the code if it is
required to be modified in any way.  In this way (bottom up for functions, top
down for system) you will be more successful than trying to crunch the entire
design.

The promise is there for some absolutely phenominal performance, but I agree, we
are at the dawn of a new age in DSP.  To call it "not ready for prime time," I
suppose is the pessimist's view of the situation.

It is the glass half full or half empty problem.

Austin

Kevin Neilson wrote:

> I have had experience integrating code generated by the Cadence SPW tool.  I
> think it is very similar to System Generator; one draws block diagrams of a
> DSP system and the tool generates Verilog.  I think the most of the problems
> I had would be the same for the whole family of tools.
>
> The tools work very well in terms of making a DSP design easier and perhaps
> more intuitive.  However problems crop up on the leading edge.  Analagous is
> how a compiler makes software design much easier but loses out to assembly
> in very critical applications.
>
> If you can meet timing, everything is fine.  But in one case, I couldn't
> meet timing with the generated code.  It was necessary to use several
> tricks, like duplicating logic similar to Shannon expansion and manually
> reducing fanout on critical nets.  The high-level tools don't deal with
> these low-level problems.  Therefore I had to manually edit the code.  This
> was a huge task, because the source generated is functionally but nearly
> unintelligible, with netnames such as n_98742 and every register set buried
> in its own module.  Again, it was like editing assembly generated by a C
> compiler.  Also, there are tricks such as using a single BRAM as two
> indpendent ROMs (saving half your BRAMs) which I don't think the generation
> tools can deal with.  In this case, I may have saved a lot of time by
> writing all the source instead of using code generated by the tool.  What I
> am left with is a bunch of unreadable hacked code, which cannot be modified
> by anyone else (nor myself), nor can the tool be used to tweak any
> parameters, because generating source from the tool again would not include
> my hacks.
>
> In summary, I believe these tools may save time, but only when there is
> plenty of margin to deal with.
>
> -Kevin
>
> "cybin" <cybin@home.com> wrote in message news:3B19B9EE.56137102@home.com...
> > I've been using system Generator for three months since it's release and
> > have found somewhat erratic performance. I would be interested in
> > sharing my experience with other System Generator users in hopes of
> > finding and sharing solutions that would be of benefit to all. Perhaps a
> > data base could be constructed outside the Xilinx infrastructure for
> > this purpose.
> >
> > Regards,
> >


Article: 31720
Subject: Re: one state machine
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 04 Jun 2001 08:36:37 -0700
Links: << >>  << T >>  << A >>
Interesting.
So there are cases where the schematic is simpler than theVHDL.
Isn't there a way ( for these cases ) to (ab)use VHDL just to verbalize the
schematic?

Peter Alfke
========================
Allan Herriman wrote:

> Peter Alfke wrote:
> >
> > This is trivial.
> > Since FPGAs use 4-input look-up tables, you can design any arbitrary 4-bit
> > counter sequence in just 4 look-up tables.
> > In your case, you need only 3 LUTs.
> > Just write down the logic equations for the three D-inputs.
> > Hint: In your case, D0 just toggles, so feed ot with Q0bar.
> > It should take you less than 15 minutes to write the three logic equations, then
> > leave it to the synthesis tool to optimize it down to  a single level of logic.
>
> I know it's "trivial" but I found it quite hard to get the best results
> from a particular VHDL synthesiser (Synplify) when I tested this.
>
> The best way to express it in VHDL seems to be to use a constant array
> to specify the state transitions
> ...
>   constant num_counts : integer := 8;
>
>   type count_array is array (0 to num_counts - 1) of integer;
>
>   constant next_count : count_array := (
>     1,6,3,0,7,4,5,2
>   );
>
>   signal count : integer range 0 to num_counts - 1;
>
> begin
>
> counter : process (clock)
> begin
>   if (rising_edge(clock)) then
>     count <= next_count(count);
>   end if;
> end process counter;
> ...
>
> Suprisingly, Synplify decided that this was best implemented as a
> one-hot, and used 6 flip flops and 3 LUTs.
>
> Recoding as:
>
>   case count is
>     when 0 => count <= 1;
>     when 1 => count <= 6;
>     when 2 => count <= 3;
>     when 3 => count <= 0;
>     when 4 => count <= 7;
>     when 5 => count <= 4;
>     when 6 => count <= 5;
>     when 7 => count <= 2;
>     when others =>
>   end case;
>
> ... gave identical results i.e. 6 flip flops and 3 LUTs.
>
> I didn't get the optimal answer (3 FF, 3 LUT, 300MHz) until I switched
> to Synplify Pro to use "FSM Explorer".  It tries different FSM encodings
> to find the best one.  It takes a while, too (about 4 seconds for this
> tiny design).
>
> Sometimes, schematics seem just so much easier.  I really hate it when
> the language and tools get in the way of getting the job done.
>
> I'd be interested in seeing the results from other VHDL synthesisers.
> (Complete source code available via email.  Remove the ".hates.spam" bit
> from my address first.)
>
> Regards,
> Allan.
>
>
> > Peter Alfke, Xilinx Applications
> > =======================
> > finish wrote:
> >
> > > hello,
> > >
> > > i can't find the clue on how to solve optimally this problem in
> > > vhdl,(or verilog), any help please!!!
> > > i want to design an irregular counter
> > > say acound modulo 8 but with these outputs
> > > [4,7,2,3,0,1,6,5]
> > >
> > > someone suggests me to design a counter and later add such similair
> > > code
> > > CASE counter IS
> > >     WHEN 0 => output <= 4;
> > >     WHEN 1 => output <= 7;
> > > .....
> > >
> > > i expect that the synthesizer will do it in 2 logic levels, whereas
> > > one logic level is feasible ?
> > >
> > > thanks


Article: 31721
Subject: Re: XtremeDSP Ready for prime time?
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 04 Jun 2001 08:48:16 -0700
Links: << >>  << T >>  << A >>
I checked into this, and here is what I learned from the Xilinx core folks:

"A major difference between the Cadence tools and the Xilinx
System Generator is that Xilinx tools map to available optimized algorithms
(LogiCOREs) such as multipliers, filters and FFTs. The Cadence tools generate
HDL code, initially intended for ASICs, often yielding bad performance in an
FPGA, as shown by Kevin.
We are trying to help Cadence to improve their flow".

Peter Alfke, Xilinx Applications



Kevin Neilson wrote:

> I have had experience integrating code generated by the Cadence SPW tool.  I
> think it is very similar to System Generator; one draws block diagrams of a
> DSP system and the tool generates Verilog.  I think the most of the problems
> I had would be the same for the whole family of tools.
>
> The tools work very well in terms of making a DSP design easier and perhaps
> more intuitive.  However problems crop up on the leading edge.  Analagous is
> how a compiler makes software design much easier but loses out to assembly
> in very critical applications.
>
> If you can meet timing, everything is fine.  But in one case, I couldn't
> meet timing with the generated code.  It was necessary to use several
> tricks, like duplicating logic similar to Shannon expansion and manually
> reducing fanout on critical nets.  The high-level tools don't deal with
> these low-level problems.  Therefore I had to manually edit the code.  This
> was a huge task, because the source generated is functionally but nearly
> unintelligible, with netnames such as n_98742 and every register set buried
> in its own module.  Again, it was like editing assembly generated by a C
> compiler.  Also, there are tricks such as using a single BRAM as two
> indpendent ROMs (saving half your BRAMs) which I don't think the generation
> tools can deal with.  In this case, I may have saved a lot of time by
> writing all the source instead of using code generated by the tool.  What I
> am left with is a bunch of unreadable hacked code, which cannot be modified
> by anyone else (nor myself), nor can the tool be used to tweak any
> parameters, because generating source from the tool again would not include
> my hacks.
>
> In summary, I believe these tools may save time, but only when there is
> plenty of margin to deal with.
>
> -Kevin
>
> "cybin" <cybin@home.com> wrote in message news:3B19B9EE.56137102@home.com...
> > I've been using system Generator for three months since it's release and
> > have found somewhat erratic performance. I would be interested in
> > sharing my experience with other System Generator users in hopes of
> > finding and sharing solutions that would be of benefit to all. Perhaps a
> > data base could be constructed outside the Xilinx infrastructure for
> > this purpose.
> >
> > Regards,
> >


Article: 31722
Subject: Xilinx Configuration Bitstream
From: "Alfredo Benso" <alfredo.benso@tiscalinet.it>
Date: Mon, 4 Jun 2001 17:59:49 +0200
Links: << >>  << T >>  << A >>
Hi everybody,
I am a researcher at Politecnico di Torino in Italy.
I am looking for information about the format of the Xilinx configuration
bit stream. Is the format public? Is there some document or file available
explaining how to generate a stream of configuration bits for a Xiling FPGA?

Anybody can help?

Thanks Alfredo

----ooo---ooo---ooo---ooo----
BENSO Alfredo, PhD

Politecnico di Torino

Dip. Automatica e Informatica

C.so Duca degli Abruzzi 24

Torino - Italy

Phone: +39-011-564.7080

Fax: +39-011-564.7099

email: alfredo.benso@polito.it

----------ooo---ooo-------------





Article: 31723
Subject: Re: XtremeDSP Ready for prime time?
From: "Kevin Neilson" <kevin_neilson@yahoo.com>
Date: Mon, 04 Jun 2001 16:30:11 GMT
Links: << >>  << T >>  << A >>
The Cadence tool isn't too bad.  At times it does seem to be generating ASIC
code, as when it prefers to make resets synchronous, but it does use CoreGen
for multipliers and BRAMs and such.

"Peter Alfke" <peter.alfke@xilinx.com> wrote in message
news:3B1BADC0.B24DC761@xilinx.com...
> I checked into this, and here is what I learned from the Xilinx core
folks:
>
> "A major difference between the Cadence tools and the Xilinx
> System Generator is that Xilinx tools map to available optimized
algorithms
> (LogiCOREs) such as multipliers, filters and FFTs. The Cadence tools
generate
> HDL code, initially intended for ASICs, often yielding bad performance in
an
> FPGA, as shown by Kevin.
> We are trying to help Cadence to improve their flow".
>
> Peter Alfke, Xilinx Applications
>
>
>
> Kevin Neilson wrote:
>
> > I have had experience integrating code generated by the Cadence SPW
tool.  I
> > think it is very similar to System Generator; one draws block diagrams
of a
> > DSP system and the tool generates Verilog.  I think the most of the
problems
> > I had would be the same for the whole family of tools.
> >
> > The tools work very well in terms of making a DSP design easier and
perhaps
> > more intuitive.  However problems crop up on the leading edge.
Analagous is
> > how a compiler makes software design much easier but loses out to
assembly
> > in very critical applications.
> >
> > If you can meet timing, everything is fine.  But in one case, I couldn't
> > meet timing with the generated code.  It was necessary to use several
> > tricks, like duplicating logic similar to Shannon expansion and manually
> > reducing fanout on critical nets.  The high-level tools don't deal with
> > these low-level problems.  Therefore I had to manually edit the code.
This
> > was a huge task, because the source generated is functionally but nearly
> > unintelligible, with netnames such as n_98742 and every register set
buried
> > in its own module.  Again, it was like editing assembly generated by a C
> > compiler.  Also, there are tricks such as using a single BRAM as two
> > indpendent ROMs (saving half your BRAMs) which I don't think the
generation
> > tools can deal with.  In this case, I may have saved a lot of time by
> > writing all the source instead of using code generated by the tool.
What I
> > am left with is a bunch of unreadable hacked code, which cannot be
modified
> > by anyone else (nor myself), nor can the tool be used to tweak any
> > parameters, because generating source from the tool again would not
include
> > my hacks.
> >
> > In summary, I believe these tools may save time, but only when there is
> > plenty of margin to deal with.
> >
> > -Kevin
> >
> > "cybin" <cybin@home.com> wrote in message
news:3B19B9EE.56137102@home.com...
> > > I've been using system Generator for three months since it's release
and
> > > have found somewhat erratic performance. I would be interested in
> > > sharing my experience with other System Generator users in hopes of
> > > finding and sharing solutions that would be of benefit to all. Perhaps
a
> > > data base could be constructed outside the Xilinx infrastructure for
> > > this purpose.
> > >
> > > Regards,
> > >
>
>



Article: 31724
Subject: Re: XtremeDSP Ready for prime time?
From: "Pete Dudley" <padudle@sandia.gov>
Date: Mon, 4 Jun 2001 10:54:29 -0600
Links: << >>  << T >>  << A >>
Cy,

We are using System Generator out here to implement some of our radar signal
processing functions. So far we have found the tool useful and we are happy
with its cost relative to SPW. Signal processing guys are able to simulate
their block diagrams and generate functions that I include in the overall
chip design. In effect they are converted to productive digital designers.

It would be interesting to us if you set up some sort of news group or
message board for these types of tools. Otherwise please post to this news
group.

Thanks,

   Pete Dudley
   padudle@sandia.gov

"cybin" <cybin@home.com> wrote in message news:3B19B9EE.56137102@home.com...
> I've been using system Generator for three months since it's release and
> have found somewhat erratic performance. I would be interested in
> sharing my experience with other System Generator users in hopes of
> finding and sharing solutions that would be of benefit to all. Perhaps a
> data base could be constructed outside the Xilinx infrastructure for
> this purpose.
>
> Regards,





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search