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 34475

Article: 34475
Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
From: "Tim" <tim@rockylogic.com.nospam.com>
Date: Mon, 27 Aug 2001 15:10:33 +0100
Links: << >>  << T >>  << A >>
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3B86F821.87AD4921@xilinx.com...

<big snip>

> > >> 7) How about guaranteed best case timings as well ?
> > >>    ( specifically for BRAM access)
> > >
> > >some day
> > >
> > Sorry It's just that I could have sworn that Xilinx indicated the
availability
> > of this data several months ago.The indication was in tabular form.
>
> Maybe for Virtex, Virtex E, but I doubt it for Spartan II.  I'll ask.

Isn't 'best case' timing only valuable in the sense of

    "path X will never be faster than path Y"

so that we can avoid races.  Otherwise, use worst case.

(I guess tricky clock-doublers are the exception)





Article: 34476
Subject: Re: Some questions about Spartan2 (& a bug report for XST sp8)
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 27 Aug 2001 08:45:32 -0700
Links: << >>  << T >>  << A >>
Mark,

Austin


>
> >(snip)
> So is there zero skew on the Data out lines ?
> Or is the skew the difference between Tbcko max & min  (1.25ns approx) ?
> Or do we use a margin such as 10% of Tbcko max          (0.33ns) ?

Assume no skew.  Let the tools do their job.  The min and max is for overall timing.  Of course there
is some skew, but it is so small as to be difficult to measure, let alone characterzie.  That is why
we depend on the tools to yield a place and route with sufficient margin.




Article: 34477
Subject: Re: Help needed: simulation OK, synthesis OK, but doesnt work :-<
From: John_H <johnhandwork@mail.com>
Date: Mon, 27 Aug 2001 15:51:48 GMT
Links: << >>  << T >>  << A >>
Simulation works because the sensitivity list in your combinatorial blocks (always@(sysclk)) only
gets executed when sysclk changes.  Synthesis won't provide you with the same kinds of results - you
have to either think in terms of registers (for a synchronous shift register) or produce some kind
of master/slave equivalent to get a true asynch system going.  Asynch is almost never the right way
to design.

The combinatorial logic produced should end up with the led_1, led_0 assignments being made
continuously while ~sysclk&&~last_ser_clk&& ser_clk not just when sys_clk changes.  This should be
visible in the synthesized results but should not simulate as the shift register you expect.  I'd
think you'd see a warning message in your synthesizer talking about an "incomplete sensitivity
list."  The incomplete lists can do nice things for simulation but not for synthesis.


Fred wrote:

> Hello,
>
> Just to get familiar with the basics of verilog and all that I tried to make
> a 16 bit shift register, and show the contents on a led display.
>
> In simulation it does all it's supposed to do. I do my simulations with
> Icarus Verilog 0.5 (g++-3.0). Now when I compile it to the target hardware,
> still everything is tip-top.  As hardware I'm using a Post-It board, which
> has an Altera EPM3128ATC100-7 on it. [http://www.cmosexod.com/board.htm]
> For synthesis I use Max+plusII version 10.0 9/14/2000 (2000.09) from Altera.
> It even programs OK. So what's the problem I hear you say?
>
> As inputs I have async_ser_clk and async_ser_clk, which change out of sync
> with the system clock of the CPLD. So on the posedge of the system clock I
> latch those to two registers to synchronize them. For debugging purposes I
> also latch them into two of the four led displays. On the negedge of the
> system clock I then check if the synchronized ser_clock has gone from low to
> high, and if so, shift the register.
>
> Now the problem is this:
> It does seem to synchronize the ser_clock, and does _something_ on the low to
> high transition. Only that something should be shift the register, like this:
> (See also the appended source-code)
>                 led_1[7] <= led_1[6];
>                 led_1[6] <= led_1[5];
> ...
>                 led_0[1] <= led_0[0];
>                 led_0[0] <= ser_dat;
>
> What it seems to do instead is:
>                 led_1[7] <= ser_dat;
>                 led_1[6] <= ser_dat;
> ...
>                 led_0[1] <= ser_dat;
>                 led_0[0] <= ser_dat;
>
> It doesn't shift, it changes _ALL_ 16 bits of the 'shift'-register to either
> 1 or 0, the value of ser_dat. Oh, and before I forget, I don't think it's a
> timing problem, since for debugging I use a system clock of 200 Hz, and
> change the async_ser_clk and async_ser_dat on the touch of a button (== as
> slow as I want). So did I make a stoopid mistake somewhere, and should it
> compile to this, or is something else going on?
>
> any help appreciated,
> Fred

<snip>

>     always @(sys_clk) begin
>         if (sys_clk) begin
>             // @(posedge sys_clk) --> synchronize ser_clk and ser_dat
>             last_ser_clk <= ser_clk;
>             ser_clk <= async_ser_clk;
>             ser_dat <= async_ser_dat;
>         end else begin
>             // @(negedge sys_clk) --> use synchronized ser_clk and ser_dat
>             led_3[7] <= ser_clk;
>             led_3[6] <= ser_clk;
>             led_3[5] <= ser_clk;
>             led_3[4] <= ser_clk;
>             led_3[3] <= ser_clk;
>             led_3[2] <= ser_clk;
>             led_3[1] <= ser_clk;
>             led_3[0] <= ser_clk;
>
>             led_2[7] <= ser_dat;
>             led_2[6] <= ser_dat;
>             led_2[5] <= ser_dat;
>             led_2[4] <= ser_dat;
>             led_2[3] <= ser_dat;
>             led_2[2] <= ser_dat;
>             led_2[1] <= ser_dat;
>             led_2[0] <= ser_dat;
>
>             if ((~last_ser_clk) && (ser_clk)) begin
>                 // @(posedge synchronized ser_clk)
>                 // shift ser_dat through
>                 // led_1 <-- led_0 <-- ser_dat
>                 led_1[7] <= led_1[6];
>                 led_1[6] <= led_1[5];
>                 led_1[5] <= led_1[4];
>                 led_1[4] <= led_1[3];
>                 led_1[3] <= led_1[2];
>                 led_1[2] <= led_1[1];
>                 led_1[1] <= led_1[0];
>                 led_1[0] <= led_0[7];
>
>                 led_0[7] <= led_0[6];
>                 led_0[6] <= led_0[5];
>                 led_0[5] <= led_0[4];
>                 led_0[4] <= led_0[3];
>                 led_0[3] <= led_0[2];
>                 led_0[2] <= led_0[1];
>                 led_0[1] <= led_0[0];
>                 led_0[0] <= ser_dat;
>             end // @(posedge synchronized ser_clk)
>         end
>     end // always @ (sys_clk)
> endmodule // shift_leds

<snip>


Article: 34478
Subject: Re: Spartan-II & clock
From: John_H <johnhandwork@mail.com>
Date: Mon, 27 Aug 2001 15:59:07 GMT
Links: << >>  << T >>  << A >>
Consider trying not to add extra clocks just because it's easy to add one
element (a counter) that works simply with an individual clock.  Often other
factors are complicated because the element is asynchronous with other parts of
your design.  If you're reading the counter with another system clock, what
happens when you read the value during an increment?  If your read is
synchronous you'll either have the previous or next value, no in-between.

My suggestion is to look for the rising edge and generate a single registered
signal for one system clock period.  When that one register is valid, enable
your count.  Everything falls into place.

Someone could provide a quick code snippet if you let us know your language -
verilog?  vhdl?  ahdl?

Schematics are tough to do in the newsgroup.



Jan Pech wrote:

> Hi all,
> I have some problem with my design in Xilinx WebPACK. I need to count events
> on an I/O pin. When I specify the pin number for counter clock signal in UCF
> file, the map process generates error 93 .......IPAD-IBUFG should only be
> LOCed to GCLKIOB site.
> I tried to instantiate BUFGP and BUFGDLL primitives between the I/O pin and
> internal clock signal but they may be used with GCLK pins only.
> Is there any way to drive clock signal for counter by an general I/O pin?
>
> Thanks for your help!
>
> Regards,
> Jan
>
> ___________________________
>      j.pech@sh.cvut.cz
>      +420 (723) 760802
>      ICQ: 56431283


Article: 34479
Subject: DUART core synthesizable in Xilinx FPGA.
From: mcastellon@csi-wireless.com (Marco Castellon)
Date: 27 Aug 2001 09:51:17 -0700
Links: << >>  << T >>  << A >>
Greetings everyone,

Does any there know of a DUART core (compatible with 16C550) that is free,
and that can be synthesized for a Xilinx FPGA (Spartan II).

Even if it isn't ready for synthesis, but that the source code in VHDL or
Verilog is available would be of great help.

Thank you in advance.
Marco.

Article: 34480
Subject: Re: System Requirements
From: "Leon Heller" <leon_heller@hotmail.com>
Date: Mon, 27 Aug 2001 18:21:45 +0100
Links: << >>  << T >>  << A >>


"H.L" <alphaboran@yahoo.com> wrote in message
news:9mcvnp$1r11$1@ulysses.noc.ntua.gr...
> Hello all,
> I am going to program a Xilinx FPGA for the first time. I wanna setup the
> synthesis tools on a pc, what must be the system's requirements for proper
> (and relatively fast) function?
> Thanks
>
>

It obviously depends on the size and complexity of your design. I find a 1
GHz Athlon with 512 Mbytes of RAM works quite well with the Xilinx and
Altera tools.

Leon
--
Leon Heller, G1HSM leon_heller@hotmail.con
http://www.geocities.com/leon_heller
Low-cost Altera Flex design kit: http://www.leonheller.com





Article: 34481
Subject: Re: DRAM burst mode
From: "Andy Peters <andy [@] exponentmedia" <".> com">
Date: Mon, 27 Aug 2001 17:35:10 GMT
Links: << >>  << T >>  << A >>
Speedy Zero Two wrote:
> 
> Hi Rick,
> 
> I already have control of the dram so know the refresh is ok but will
> probably modify the code for future design checking.
> What I found in the verilog code confirmed what I thought, I am already
> using the burst mode but for a single "word".
> Now all I have to do is change the mode register to give the required burst
> length (which is all I really need).

Part of your logic should be setting that mode register at
initialization time...

-a

Article: 34482
Subject: Re: Slowing PCI for FPGA
From: Kolja Sulimma <kolja@sulimma.de>
Date: Mon, 27 Aug 2001 20:07:04 +0200
Links: << >>  << T >>  << A >>
I did not expect to participate in this pointless argument, but enough is
enough...

Austin Franklin wrote:

>> but so does "proper
>> use of schematics", correct?
>
> Er, no it doesn't.  Same schematic, same results.

Errr...
If I do schematic entry, I expect from a good tool chain, that it
performs at least the following optimizations:

- logic minimization
- redundancy elimination
- retiming
- logic replication for speed-up
- technology mapping

There are many algorithms for these optimizations and even if there
wasn't the results would depend on the order the circuit is processed in.
Also, there are area, speed, power and  testability trade-offs in these
steps and relative weights may differ from version to version.

Of course you can draw schematics that are completly based on technology
dependant elements so there is no technology mapping.

Probably your tool is one of the many that does not implement retiming.
One point for predictability but minus ten for performance.

You probably turned off logic replication for your tool because you believe that
you
can handle that manually. You don't. Not  for large designs. Especially
not if retiming is involved.

And of course your schematics are allready minimal and do not contain
any redundancies...

The only way to be really sure what comes out of the tools is to do it manually.
(The assembler equivalent)
You can do that in JBits, FPGA Editor, low level schematic entry and structural
VHDL using library primitives..

But time to market wise state machine diagrams, high level schematic abstraction
or higher level hdl are going to beat you by huge factors.

And also performance wise: Especially simultaneous retiming and placement is
somthing that you can hardly do manually and it can get you a huge performance
boost...

Kolja Sulimma





Article: 34483
Subject: Looking for a synthesizable JPEG coder core
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: Mon, 27 Aug 2001 14:23:42 -0400
Links: << >>  << T >>  << A >>
- Grayscale (8 bit) video input
- Compression only, baseline lossy JPEG (ISP/IEC 10918-1) only required
- VHDL or Verilog
- Planning on targetting an FPGA

Thanks in advance



Article: 34484
Subject: Re: Xilinx FPGA Editor - how to route to an internal macro net?
From: arast@inficom.com (Alex Rast)
Date: Mon, 27 Aug 2001 20:09:17 GMT
Links: << >>  << T >>  << A >>
In article <3b86ed56.46990212@news.compuserve.com>, 101551.3434@compuserve.com (Mark Taylor) wrote:
>On Fri, 24 Aug 2001 00:19:48 GMT, arast@inficom.com (Alex Rast) wrote:
>
>>This is one I think I've done before, so I probably just need my memory 
>>jogged. I'm sure it's something that happens, and that you need, all the time.
>>
>>I've defined a hard macro, call it custommacro.nmc. .... Now, at least one of the nets connects to an 
>>external pin and an internal route. One common example, for instance, is CLK. 
>>You want the signal to be common to the internal CLB's of the macro and to 
>>connect to external routes (in the case of CLK, to the global clock net). 
>>
>
>As far as I know, nets could never be included in hard macros.
>(despite documentation suggesting otherwise, right back to before EPIC)

No, I have no problem including a net in a macro. What I have difficulty doing 
is routing an external net *to* the macro's internal net.

>Just use the hard macro to configure slices/CLBs or whatever,
>then embed the macro within a soft macro
> (ie a schematic macro with  RLOCS).
>The soft macro can contain all the routing.

I don't think this would work, for 2 reasons. First, I *have* to have a 
specific routing within the hard macro (indeed, the routing itself is a key 
part of the design), so I can't afford to let the software take care of any 
routing at the hardware level. Second, a lot of the things we're doing are 
functions you simply can't enter properly in Schematic Editor, not because you 
can't implement them on-chip, but because the programmers didn't anticipate 
you'd be doing these kinds of functions. Just for giggles, I decided to input 
the closest approximation to our macro you could do in Schematic Editor. The 
resultant imlementation, in addition to being close but not exactly the same 
in functionality, occupied 6 times as many CLB's! This is kind of the result I 
was expecting, because it's clear the program doesn't think of or implement 
resource reuse, i.e. using the same logic elements to implement multiple 
functions, nor will it use multiple data paths within the same CLB, i.e. using 
different data outputs to generate different function outputs. It thinks of a 
CLB slice implementing one function. Are you thinking along some other line? 
If so, can you clarify what your approach would be?

Alex Rast
arast@inficom.com
arast@qwest.net

Article: 34485
Subject: FPGA : USB in an FPGA, has anyone done it before?
From: Moadl <mkeller@fh-landshut.de>
Date: Mon, 27 Aug 2001 13:54:04 -0700
Links: << >>  << T >>  << A >>
Hi all,

at the moment I'm thinking of using an FPGA from brand X to implement a USB interface. What I heard from brand X is that I should translate USB with 'You shouldn't bother' but that's not an answer I really want.

So I'm wondering if anyone out there has successfully implemented a USB-interface in a Xilinx-FPGA or is this really something I should do in another way?

Help would be very much appriciated.

Moadl

Article: 34486
Subject: Re: DUART core synthesizable in Xilinx FPGA.
From: sknapp@triscend.com (Steven K. Knapp)
Date: 27 Aug 2001 13:56:18 -0700
Links: << >>  << T >>  << A >>
You might check out the following from OpenCores.org

http://www.opencores.org/cores/uart16550/



mcastellon@csi-wireless.com (Marco Castellon) wrote in message news:<852c162d.0108270851.215952d1@posting.google.com>...
> Greetings everyone,
> 
> Does any there know of a DUART core (compatible with 16C550) that is free,
> and that can be synthesized for a Xilinx FPGA (Spartan II).
> 
> Even if it isn't ready for synthesis, but that the source code in VHDL or
> Verilog is available would be of great help.
> 
> Thank you in advance.
> Marco.

Article: 34487
Subject: FPGA to ASIC conversion?
From: kenm@morro.co.uk (Ken Morrow)
Date: 27 Aug 2001 14:32:27 -0700
Links: << >>  << T >>  << A >>
One of my customers would like an FPGA converted to a pin for pin compatible
ASIC, in order to try to prevent counterfeit versions of their product being
manufactured.

I have used ASIC Technical Solutions (ATS) for this successfully in the past,
but they seem to have disappeared.

I am looking at AMIS and Flextronics.

Does anyone know of any other companies, or have any other suggestions?

Many Thanks,

Ken Morrow,
Morrow Electronics Limited, UK.

Article: 34488
Subject: Re: FPGA to ASIC conversion?
From: Muzaffer Kal <muzaffer@dspia.com>
Date: Mon, 27 Aug 2001 15:07:22 -0700
Links: << >>  << T >>  << A >>
kenm@morro.co.uk (Ken Morrow) wrote:

>One of my customers would like an FPGA converted to a pin for pin compatible
>ASIC, in order to try to prevent counterfeit versions of their product being
>manufactured.
>
>I have used ASIC Technical Solutions (ATS) for this successfully in the past,
>but they seem to have disappeared.
>
>I am looking at AMIS and Flextronics.
>
>Does anyone know of any other companies, or have any other suggestions?
>
>Many Thanks,
>
>Ken Morrow,
>Morrow Electronics Limited, UK.

Check out http://www.simtek.com/Logic/logic-overview.htm. A client of
mine is currently using them to convert an Altera 10K design.

Muzaffer

Article: 34489
(removed)


Article: 34490
Subject: Re: Polyphase adjustment to keep it working
From: "Daniel Nilsson" <danielnilsson@REMOVE_THIShem3.passagen.se>
Date: Tue, 28 Aug 2001 03:09:13 +0200
Links: << >>  << T >>  << A >>
Try asking in comp.dsp



Article: 34491
Subject: Re: FPGA to ASIC conversion?
From: "Eric Braeden" <braeden@erinet.com>
Date: Mon, 27 Aug 2001 21:19:05 -0400
Links: << >>  << T >>  << A >>
Depending on the volume might it not be cheaper to go with
an anti-fuse part for this? ASICs are actually __easier__ to
counterfeit than anti-fuse parts.

Eric

"Ken Morrow" <kenm@morro.co.uk> wrote in message
news:20f8de50.0108271332.3378e62e@posting.google.com...
> One of my customers would like an FPGA converted to a pin for pin
compatible
> ASIC, in order to try to prevent counterfeit versions of their product
being
> manufactured.
>
> I have used ASIC Technical Solutions (ATS) for this successfully in the
past,
> but they seem to have disappeared.
>
> I am looking at AMIS and Flextronics.
>
> Does anyone know of any other companies, or have any other suggestions?
>
> Many Thanks,
>
> Ken Morrow,
> Morrow Electronics Limited, UK.



Article: 34492
Subject: Re: FPGA to ASIC conversion?
From: "Kevin Neilson" <kevin_neilson@removethis-yahoo.com>
Date: Tue, 28 Aug 2001 01:23:13 GMT
Links: << >>  << T >>  << A >>
I think you can use the new Virtex II bitstream encryption in this case.

If the customer ships the board, I think they can program encryption keys
into the VirtexII in the factory.  Then they encrypt their bitstream with
the same key.

Then the board can't be reverse engineered.  A reverse engineer could
intercept the bitstream as it programs the Virtex, but if he tries to
program another Virtex with the same bitstream, it won't work because he
first has to program the Virtex encryption key, which can't be read from the
original part.

-Kevin

"Ken Morrow" <kenm@morro.co.uk> wrote in message
news:20f8de50.0108271332.3378e62e@posting.google.com...
> One of my customers would like an FPGA converted to a pin for pin
compatible
> ASIC, in order to try to prevent counterfeit versions of their product
being
> manufactured.
>
> I have used ASIC Technical Solutions (ATS) for this successfully in the
past,
> but they seem to have disappeared.
>
> I am looking at AMIS and Flextronics.
>
> Does anyone know of any other companies, or have any other suggestions?
>
> Many Thanks,
>
> Ken Morrow,
> Morrow Electronics Limited, UK.
>



Article: 34493
(removed)


Article: 34494
Subject: Re: Slowing PCI for FPGA
From: Phil Hays <spampostmaster@home.com>
Date: Tue, 28 Aug 2001 03:55:19 GMT
Links: << >>  << T >>  << A >>
Austin Franklin wrote:
 
> > > > > > Yet the majority of designs are done in HDL for
> > > > > > good reasons:  less effort, better results.
> > > > >
> > > > > You have no proof of this.
> > > >
> > > > That's correct, for I don't think such things can be proven.  Do you?
> > >
> > > Then why did you make a claim that you know isn't true?
> >
> > As Godel showed, propositions can be both true and unprovable.
> 
> Well, then I clam that schematics are less effort and give better results.

I agree with you, for designs that are both large and are not complex, or for
which large amounts of effort can be expended for marginal improvements.


> > > I've done a number of designs in both, and schematics win hands down to
> > > finished product every time, except for the simplest/slowest designs.
> >
> > Back when synthesis got started, designers were drawing transistors on
> > schematics and wanted a faster way to an acceptable answer.  Sure, by
> > calculations and experience the human designer can produce a nearly
> > optimal design for a bit of logic (say for the carry bit of an ALU, 
> > perhaps some 20 or 30 transistors, using many hours of human designer 
> > time: but a simple synthesis tool can do nearly as well in seconds.  By 
> > freeing the designer from the tiny details of transistors and gates, 
> > much more complex designs could be completed.
> 
> I don't get your point.  There is no need to draw gates with schematics, any
> more so that you do with HDLs.

I'd bet that the schematics for "our beloved FPGAs" have gate sizes on them.  I
might be wrong, I've been out of the semiconductor world for a long time.


> > > There can be way too much fussing with timing and tools etc. with 
> > > synthesis.  When synthesis works, it works, and that's nice...but 
> > > there is no guarantee that it will, and if it doesn't, the amount 
> > > of time it takes to get it to work can be exponential, or even 
> > > complete failure.
> >
> > When I write code I know fairly closely what the synthesis tool is going
> > to produce,
> 
> Do you look at the gates that the synthesis tool generates?

Often.  Usually on critical paths, or on close to critical paths where the
synthesis tool didn't build good logic or where MAP and/or PAR needed some hints
and one of these issues caused the design to fail timing on these paths.  And
yes, the shame of it, the viewer is a schematic viewer (Synplicity's "technology
view").  And yes, the solution is often "schematic VHDL", i.e. instantiate
LUTs.  In designs I've done the amount of LUTs that needs this sort of treatment
has averaged less than a few percent of the total.


> > and how fast it will run.  This takes experience,
> 
> More than experience.  It takes only using one revision of one tool!  The
> synthesized code will give different results based on a LOT of variables,
> even point revisions of the tools.  You can't guarantee that.

If you want the best guaranteed results, specify gate sizes and do the layout
yourself, and don't expect to do many complex designs in your lifetime.  The
best is the worst enemy of the good.


> Unless there
> is a document that synthesis tool vendors provide that shows EXACTLY what
> code is generated for each construct, what you suggest just isn't going to
> work.

This can be done, if required.  Not for "each construct", but you can build an
EXACT design by mapping primitive elements.  Yet why bother, for complex
designs, except for the critical paths?  Let the tool handle all but the
critical stuff.


-- 
Phil Hays

Article: 34495
Subject: IEEE 1149.1-1990
From: "Daniel Nilsson" <danielnilsson@REMOVE_THIShem3.passagen.se>
Date: Tue, 28 Aug 2001 06:00:35 +0200
Links: << >>  << T >>  << A >>
Hi.
I need the IEEE 1149.1-1990 standard, I am not interrested in paying IEEE
for the book, so .pdf is preferred

/ Daniel Nilsson



Article: 34496
Subject: Re: Help needed: simulation OK, synthesis OK, but doesnt work :-<
From: lingbo <mcmzhh@sina.com>
Date: Mon, 27 Aug 2001 21:13:14 -0700
Links: << >>  << T >>  << A >>
I want to ask a question about the   synthesis and simulation.
After synthesis with the syplify,
how can i do a post-simulation.
And what must be noted in the process of synthesis and simulation(detailed ).
Thank you .Waiting for your reply.

Article: 34497
(removed)


Article: 34498
Subject: Defending Austin Franklin
From: Philip Freidin <philip@fliptronics.com>
Date: Mon, 27 Aug 2001 21:42:47 -0700
Links: << >>  << T >>  << A >>

On Mon, 27 Aug 2001 20:07:04 +0200, Kolja Sulimma <kolja@sulimma.de> wrote:
>I did not expect to participate in this pointless argument, but enough is
>enough...

And I didn't think I would ever defend Austin Franklin (he does well enough
on his own), but this is outrageous.

But just so you have me pegged correctly for this flame fest,
note that I am an active user of Verilog and Schematic, and
have done more than enough VHDL too. I actively use Verilog
in my day to day consulting, by choice.

>Austin Franklin wrote:
> 
>>> but so does "proper
>>> use of schematics", correct?
>>
>> Er, no it doesn't.  Same schematic, same results.
>
>Errr...
>If I do schematic entry, I expect from a good tool chain, that it
>performs at least the following optimizations:
>
>- logic minimization
>- redundancy elimination
>- retiming
>- logic replication for speed-up
>- technology mapping

So are we talking about the schematic flow upto the point where
the netlist enters something like the Xilinx place and route tools,
or are we talking about including that too?

The 5 items you list are all performed by sythesis before the
netlist is passed to the P&R tools.

None of the 5 things you list should be done in a schematic flow
before the netlist is passed to the P&R tools.

Once the P&R tools get the netlist, both flows look the same.
In Xilinx's case, the current tools perform  items 1, 2, 4, and 5 .
Item 3 does not occur in the Xilinx P&R tools currently.

For each of the optimizations that the P&R tools perform, there
are cases where the result is disastrous. One of the still most
compelling reasons to still use schematics, is that there are
reasonably easy ways to inhibit this behaviour.

I would be outraged if a schematic base tool chain did ANY of
these things to the netlist before passing it on to the P&R tools,
the way synthesis does. One of the most compelling reasons for
using schematics is that you get EXACTLY what you ask for.

Certainly for expert users of FPGAs, the skills and understanding
of the target architecture allow for designs that extract the very most
out of what the chip can achieve. This often far outperforms what
synthesis tools create, because synthesis tools can't see the
big picture, and it makes pessimizations.

(And if you didn't think "pessimizations" is a word, try this:
   http://www.google.com/search?q=pessimizations&btnG=Google+Search
)

Of the 5 example design permutations you list (what you call optimizations)
here is the score for the following schematic systems, upto the point
where the netlist is passed to the P&R tools.

ViewDraw:		NONE
Orcad:			NONE
Aldec:			NONE
Cadence:		NONE
ECS:			NONE
FutureNet:		NONE
Schema:			NONE
Protel:			NONE

I wonder if there is a theme here. It seems none of the schematic systems
I have listed do any of the "optimizations" you said are expected from a
schematic flow. Here's your quote again:

>If I do schematic entry, I expect from a good tool chain, that it
>performs at least the following optimizations:

But maybe you meant the whole tool chain, including P&R.
But then, as I have pointed out, these optimizations have nothing to do
with the pros/cons of using schematics.

Now, if you didn't care about getting the most out of the FPGA, or
cared far more about design time, you can skip the rest of what I have
to say.

>There are many algorithms for these optimizations and even if there
>wasn't the results would depend on the order the circuit is processed in.
>Also, there are area, speed, power and  testability trade-offs in these
>steps and relative weights may differ from version to version.

None of which has anything to do with the schematic part of the flow.

>Of course you can draw schematics that are completly based on technology
>dependant elements so there is no technology mapping.

Or you can use technology independent libraries, like the current Xilinx
Unilib libraries, where the technology dependence is hidden in the
schematic library, and the top level symbols that you use are technology
independent. Unlike synthesis, where I have to push a design through the
tools before I have a hope at finding out how something will be mapped,
with the technology independent schematic library, I just push into the sub
page of the symbol, and I see the technology dependent implementation.

For example, the Xilinx Unilib library has a 16 bit counter called CC16RE,
and the symbol is identical, regardless of the target FPGA technology.
A schematic that uses it will work regardless whether the target is any
of the following:

	XC4000  /  XC4000E  /  SPARTAN  /  XC4000EX  /  XC4000XL
	XC5200
	VIRTEX  /  SPARTAN-II
	VIRTEX-II

The implementation is different for each of these, yet you can do
technology independent designs, with design reuse, just fine.

>Probably your tool is one of the many that does not implement retiming.
>One point for predictability but minus ten for performance.

Boy would I be pissed if the Schematic part of the flow thought it
could do pipelined design better than me.

>You probably turned off logic replication for your tool because you
>believe that you can handle that manually.
>You don't. Not  for large designs. Especially not if retiming is involved.

That may be your problem, but I know Austin well enough, that if he
decided that he could do logic replication or pipeline partitioning better
than the tool flow, it would be because he could. And it would probably
be because he had already seen the tools make a complete mess of it.

I've certainly seen the tools take a perfectly reasonable design that
could meet the design goals, and turn it into mush.

>And of course your schematics are allready minimal and do not contain
>any redundancies...

Right.

>The only way to be really sure what comes out of the tools is to do it manually.
>(The assembler equivalent)

Wrong.

>You can do that in JBits, FPGA Editor, low level schematic entry and structural
>VHDL using library primitives..

And with high level schematics too. I.E. with complex macros, and sophisticated
libraries, and design re-use, and generated IP, and purchased cores.

>But time to market wise state machine diagrams, high level schematic abstraction
>or higher level hdl are going to beat you by huge factors.

Well, Austin and I disagree.

>And also performance wise: Especially simultaneous retiming and placement is
>somthing that you can hardly do manually and it can get you a huge performance
>boost...

Totally disagree. Just because (you?) can hardly do it does not mean others
can't .

>Kolja Sulimma

Looking for a flame proof vest .....

Philip Freidin
Verilog and Schematic user.

  .... count to ten  .... hit send  :-)



Philip Freidin
Fliptronics

Article: 34499
Subject: download bitstream to FPGA
From: <khtsoi@pc90026.cse.cuhk.edu.hk>
Date: 28 Aug 2001 06:15:00 GMT
Links: << >>  << T >>  << A >>
Hi,

I want to download a bitstream (*.bit file) to a Xilinx
FPGA (e.g. xcv600) through a DB9 serial cable (model: DLC4).
Must I use the tools provided by Xilinx? Is there any
possibility I can write a segment of codes to do this in
my application? Thanks in advnce!

---- Brittle



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