Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
> 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: 31701Austin 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
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
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
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: 31705You 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
"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-CaliforniaArticle: 31707
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 ? > > thanksArticle: 31708
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: 31710I mean of pub license like some linux software or demo or shareware. thank you.Article: 31711
does anyone have a disassembler for a 18P8 PAL? I needArticle: 31713
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: 31714Hi 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 8QQArticle: 31715
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 ? > > > > thanksArticle: 31716
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 SulimmaArticle: 31717
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: 31718I 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.hrArticle: 31719
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
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 ? > > > > > > thanksArticle: 31721
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
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
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
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:
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