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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 111350

Article: 111350
Subject: Re: Need just a few 5V Spartan
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Wed, 01 Nov 2006 17:58:47 -0600
Links: << >>  << T >>  << A >>


Jon Elson wrote:

>
>
> Uwe Bonnes wrote:
>
>> Jon Elson <elson@pico-systems.com> wrote:
>> ...
>>  
>>
>>> Maybe I made a mistake, but this product uses a pretty small FPGA
>>> by today's standards.  I can get the XC2S50-something-TQ144C for
>>> $12, I know how to mount it to a board myself, etc.  A number of the
>>> newer stuff is in packages I at least am not so sure I can handle.
>>>   
>>
>>
>> At digikey, a XC3S100E-4TQG144C costs 7.45EUR and is configurable by 
>> cheap SPI flash...
>>  
>>
> Way too small, if I interpret the # of blocks correctly.  The XCS30 
> has 576
> LUT cells, the XC3S100E has only 240.  I don't think you can compare them
> exactly, but if I'm interpreting the numbers right, it means that what 
> fits
> snugly in the XCS30 is far away from fitting in the XC3S100E.

After checking the data sheet, I see the Spartan 3E CLB has a LOT more 
resources
than the old Spartan.  So, it looks like the 3S100E should, indeed, be 
big enough.
And, it's appetite for config bits is not any worse than the 2S50E.  So, 
I guess this
choice is still open.  The 3S100E is a bit cheaper than the 2S50E, and 
should stay
available from convenient distributors for a while longer.  So, I may 
have to
re-think this.  I'm pretty sure my scheme for loading the config from a
SST serial flash memory would work as well with the 3S100E as on the 2S50E.
I have to look into how well that will work on 2.5 V - it may not.

Jon


Article: 111351
Subject: Re: De-serializer using Xilinx DCM
From: Ray Andraka <ray@andraka.com>
Date: Wed, 01 Nov 2006 19:21:15 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Questions:
> Are the 25 MHz and 200 MHz phase-coherent, or is there a drift between
> the frequencies?
> Does the 8-bit word have a start-bit?
> What is the encoding scheme, I suppose NRZ (High=1, Low=0)
> Is the data stream continuous?
> These questions are somewhat interdependent.
> Food for thought...The learning is yours
> Peter Alfke


Peter,  If I understood his original post correctly, the first question 
is what he was asking of you, as I believe he intends to derive both 
clocks from the same DCM.

The answer is it depends on the set up of the DCM.  if you use the clkdv 
outputs and supply the DCM with 200 MHz (0r 100MHz using the clk2x 
output), the clocks will be pretty well aligned in most cases.  If you 
use a 25MHz clock and the clkfx to multiply up, the clkfx will exhibit a 
bit of jitter and the alignment may not be perfect (assuming the Mand D 
are set for an integer multiplication of the clock).  So in an ideal 
world, you should be able to cross between the domains...

However, it would be prudent to treat the clock domain crossings more 
carefully.  Jitter on the input clock can lead to a greater separation 
between the edges that could get you into trouble (I ran into a case 
like this when SpartanII was new, where we saw clock jitter on the DLL 
input result in a large skew - close to 1ns - between the 1x and 2x 
clocks out of the same DLL, and most of the clock jitter was not visible 
at the clock input pin because it was getting introduced by many outputs 
on the same bank as the clock input switching on the same clock edge).


Article: 111352
Subject: Re: Taking forever to synthesise (XILINX ISE 8.1i)
From: "Kryten" <kryten_droid_obfusticator@ntlworld.com>
Date: Thu, 02 Nov 2006 00:49:06 GMT
Links: << >>  << T >>  << A >>
"daver2" <davidroberts@siemens.com> wrote in message 
news:1162290502.133488.262030@e64g2000cwd.googlegroups.com...

> Thanks for the reply. I found your website previously and have it
> bookmarked as a reference!

> Well, there is nothing stopping two (or more) people from implementing
> the AGC in VHDL!!!

In my case, lack of time is stopping me doing much at all...

It's an interesting project but it isn't as impressive or fun to the layman 
as something that plays Pong or MP3 files.

Any ideas for other programs it could run?

Maybe a simple musical program to play "Ground Control to Major Tom" for 
instance?

> I have implemented the DSKY in 'proper' VHDL and this seems to work
> beautifully.

Cool. I've not explored all the abilities of VHDL yet, just enough to 
synthesise the logic I want for my projects.

> extremely pretty, large, green, 7-segment LED displays

I recall the display took up a large percentage of the power.

I'd want to use small, high efficiency LEDs to minimise power.

I'm sure they could be smaller than the original machine and yet be just as 
practical.








Article: 111353
Subject: Re: De-serializer using Xilinx DCM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 1 Nov 2006 17:47:55 -0800
Links: << >>  << T >>  << A >>
Ray, some people my have more patience than I do.
I just don't like being jerked around with half-cooked questions.
I think he has a 25 MHz clock, and wants to recover a 200 MHz bit
stream. But after that it's all very murky.
On top of all, it's just a mental exercise for him.
He has posted 4 times, and we still do not know what he wants...
Peter

On Nov 1, 4:21 pm, Ray Andraka <r...@andraka.com> wrote:
> Peter Alfke wrote:
> > Questions:
> > Are the 25 MHz and 200 MHz phase-coherent, or is there a drift between
> > the frequencies?
> > Does the 8-bit word have a start-bit?
> > What is the encoding scheme, I suppose NRZ (High=1, Low=0)
> > Is the data stream continuous?
> > These questions are somewhat interdependent.
> > Food for thought...The learning is yours
> > Peter AlfkePeter,  If I understood his original post correctly, the first question
> is what he was asking of you, as I believe he intends to derive both
> clocks from the same DCM.
>
> The answer is it depends on the set up of the DCM.  if you use the clkdv
> outputs and supply the DCM with 200 MHz (0r 100MHz using the clk2x
> output), the clocks will be pretty well aligned in most cases.  If you
> use a 25MHz clock and the clkfx to multiply up, the clkfx will exhibit a
> bit of jitter and the alignment may not be perfect (assuming the Mand D
> are set for an integer multiplication of the clock).  So in an ideal
> world, you should be able to cross between the domains...
>
> However, it would be prudent to treat the clock domain crossings more
> carefully.  Jitter on the input clock can lead to a greater separation
> between the edges that could get you into trouble (I ran into a case
> like this when SpartanII was new, where we saw clock jitter on the DLL
> input result in a large skew - close to 1ns - between the 1x and 2x
> clocks out of the same DLL, and most of the clock jitter was not visible
> at the clock input pin because it was getting introduced by many outputs
> on the same bank as the clock input switching on the same clock edge).


Article: 111354
Subject: Dual-port BlockRAM "write first" puzzler...
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 1 Nov 2006 18:22:46 -0800
Links: << >>  << T >>  << A >>

The setup:
Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write
first" mode.
Both ports have the same (global) clock and the same address, with
Enable tied high,
so they are both always reading.

Part 1:
Cycle 0- (init value) WE to port A, with DI = 0.
Cycle 1- (change value) WE to port A, with DI = 1.
Cycle 2- (cycle 1 results) Output A is 1 because it is in write first
mode and 1 was written in cycle 1.
What is value at output B during cycle 2?
 a) 0 because port B is not being written to, and reflects the value it
would have read if there was no activity on port A.
 b) 1 because port A is in write first mode, and the activity on port A
interferes with port B.
 c) x Don't do this, the result is indeterminate.

Part 2: same as part 1, with A and B switched
Cycle 0- (init value) WE to port B, with DI = 0.
Cycle 1- (change value) WE to port B, with DI = 1.
Cycle 2- Value at output B is 1 because it is in write first mode and 1
was written in cycle 1.
What is the value at output A during cycle 2?
 a) 0 ...
 b) 1 ...
 c) x ... I said don't do this!!!

I'm hoping the answer to both Part 1 and Part 2 is a), because it
simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates
muxes and registers external to the RAM, and this is going into an
already very tight design).

Peter tells me c) for both (I think).

Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a
result of b) for Part 1, and a result of a) for Part 2.

My first instinct is to trust Peter, but the fact that the XST user
guide gives deterministic code gives me pause.

So I put it to the group, hoping someone has actually used this setup
and has some definite answer.
I'm a day away from coding up a test circuit to find out what the
silicon really does, but if anyone knows of anyplace where operation in
this scenario might be documented, it would save me a few hours.
Thanks all,
Just John


Article: 111355
Subject: Re: Spectre of Metastability Update
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 03:26:14 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1162418895.253069.240680@f16g2000cwb.googlegroups.com...
>I remember the birth of the 22V10 (it's an AMD product, not MMI's)
> It had the gestation period of an elephant, and it almost killed the
> design engineers. Too complicated...
> Times have changed.
> Peter Alfke

Yes, those 'V' parts were pretty versatile (hence the 'V' in 16V8, 22V10) 
for those of us around at the birth of the 16R4, 16R6 and 16R8 when great 
thought had to be applied to decide whether an output should be clocked or 
combinatorial...and if you got it wrong you had to rewire the circuit board 
to move it to the appropriate pin....well, that and having to remove and 
pitch the part because it was fuse based one time programmable.

KJ...feeling ooooooold now....where's my hot cocoa? 



Article: 111356
Subject: Re: Need flash adc with plcc format?
From: "Matthew Hicks" <mdhicks2@uiuc.edu>
Date: Wed, 1 Nov 2006 21:33:39 -0600
Links: << >>  << T >>  << A >>
Is there a good reference for the types of IC packages and their effects on 
SI?


---Matthew Hicks


"Symon" <symon_brewer@hotmail.com> wrote in message 
news:454928a8$1_1@x-privat.org...
> <nnn> wrote in message news:4548ffa9_1@mk-nntp-2.news.uk.tiscali.com...
>> Is there a flash adc with a plcc package, anything
>> above 24MHz minimum sample rate will suit me.
>> tnx
>>
> You know this is comp.arch.fpga, right? ;-)
>
> Anyway, go search for yourself :- http://www.interfacebus.com/
>
> I doubt anyone would make a high speed ADC in a PLCC package, this type of 
> package has awful SI properties.
>
> HTH, Syms.
> 



Article: 111357
Subject: Re: Dual Port RAM
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:02:31 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1162345630.497517.281500@h48g2000cwc.googlegroups.com...
> KJ, You like standards.
> We just finished implementing PCIexpress. When I look at the complexity
> of that standard, I just cringe. I cannot fathom why one needs so much
> stuff to communicate data. But then I am old frugal and basic guy who
> believes in simplicity.
But again, you're probably standards compliant on the physical pin side but 
what about on the 'other' side?  A communication's bridge exists because it 
connects TWO disparate interfaces, so what is the standard interface that is 
used internal to the FPGA that you're bridging over to PCIexpress?

And I agree with you about frugality.  The 'internal to the chip' standard 
interface should be something robust yet something that when used in simple 
comm situations reduces down (via the magic of synthesis logic optomization) 
to something darn close to the bare minimum.  Certainly there are cases 
where anything over the bare minimum might be too much, but those tend to be 
exceptions (i.e. relatively small logic that can be hand optomized in the 
grand scheme of the entire FPGA design).

> Talking about a FIFO, what other standard interface do you want, except
> data-in, data-out, 2 clocks, 2 enables, 4 flags and perhaps a reset?
> Isn't that about as generic as it can get? Why would Altera do it
> differently, except that they don't have a hard-coded 550 MHz one...
OK, let's discuss the fifo.  Specifically let's take the EIA standard 
lpm_fifo.  That entity defines the input for a hunk-o-code that implements a 
fifo.  If I instantiate an lpm_fifo and target that to the appropriate 
Xilinx part will I get that 550 MHz performance?  If so, then you've 
provided an example of where standardizing on the interface is a 'good' 
thing.  If not, then can you explain what is so burdensome about the entity 
definition of lpm_fifo that makes that 550 MHz unachievable?

We're not talking about getting extra functionality, we're talking about 
getting the same function.  The synthesis operation, once it saw 'lpm_fifo' 
and targetting brand X could know that there is a hard coded thingy to 
implement it....that's what we pay the synthesis tool to do, right?

Now granted the 'lpm_fifo' is not necessarily the best and grandest thing to 
talk about optomizing but you brought up the fifo.  Things like controllers 
come to mind as well (i.e. I2C, DDR, SDRAM, PCI, blah, blah, blah).  Many of 
these are really communication's bridges that hook two different busses 
together to exchange information.  One one side (the physical pin side) we 
have all the standards, on the other side...well...a bit lacking (IMO) in 
calling things a standard....and yet things like Wishbone or Avalon or what 
have you that were all thought through of as being an 'inside the chip' comm 
bus really do synthesize and logically optomize quite well.

After getting over the worry (if there is any) about people jumping ship 
because their code could now be truly portable to brand A, B, C.... you 
should also recognize that it would also be a productivity improvement 
because it would improve code reuse and aid in simply division of labor 
because you wouldn't have these ad hoc, "let me pass you this signal it will 
happen two clock cycles before that" type of thing.

Perhaps instead of bantering about specific examples that we each seem to 
think bolster our points you can give us the Xilinx view of
- Standardized internal interfaces, good for business?  (Xilinx that is)
- What standards work for these internal interfaces are you compliant with?
- What push for improving these standards are you participating in?

In my view this internal interface should scale well (i.e. not get 
burdensome in wasting logic resources in the synthesized design) if I want 
to use it inside a VHDL architecture to communicate between processes all 
the way up to it being an external interface (if I so choose).

> I vote for smarter synthesis tool that interprete your intentions in
> the best possible way.
So do I.

KJ 



Article: 111358
Subject: Re: Yet Another Survey: What are code generators worth?(was: Re: Survey: simulator usage)
From: "bronzefury" <r.oteyza@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:07:28 GMT
Links: << >>  << T >>  << A >>

Personally, I would avoid code generators to generate RTL for design. 
Coding RTL is not a bottleneck for me, even on multi-million gate designs. 
Some IP is provided by 3rd-party, other IP our developers code.  It is 
fairly easy to write Verilog once you have tried and true coding style.  Why 
would I want to learn a proprietary  language to generate a standard 
language?  (and get locked-in?).  In addition, I know exactly what hardware 
I'll generate when I code.  For logic circuits that are used often, the HDL 
addresses that by allowing designers to create modules or primitives.  Who 
knows what a code generator will output.  I also wouldn't want to be locked 
in to a proprietary.

System Verilog addresses many of the my department's needs.

Even if a big name EDA company were to come out with one, I doubt this type 
of tool would be purchased.

I think if you want to attack something in the area of chip design, you've 
got to address the parts in the design flow that addresses a company's 
development bottlenecks such as verification or physical design.


"Thomas" <dtsi.india@gmail.com> wrote in message 
news:1162397407.320469.86740@h48g2000cwc.googlegroups.com...
> Generalising the question of this discussion I would like to know what
> does the group here think that code generators are worth?
>
> Say Someone comes out with a code generator which requires some  input
> data say, D_in and generates a bunch of output code say, C_out.
>
> Given that C_out is something that you already write for your design
> wether the code generator exists or not, when will the code generator
> look like a fesible option?
>
> Given the following man days(Including coding, verfying and debugging
> time) for writing  D_in and generating C_out VS manual writing of
> C_out, what is the price you will be willing to pay for the code
> generator in each case?
> ---------------------------------------------
> Development time in Mandays
> ---------------------------------------------
> D_in :      Manual C_out
> ---------------------------------------------
> 1     :      10
> 1     :      100
> 1     :      1000
>
> If such a code generator appears on the market will your management
> wait until a bigname EDA comes out with a me too product or will they
> buy it from a noname developer?
> Regards
> Thomas
>
> Andy wrote:
>> Evan Lavelle wrote:
>> > Ok, is it worth any more than $0 now? :)
>>
>> In a word, no.
>>
>> Why go to the trouble of learning a new language to try to do things
>> like macros, loops, random stimulus, etc. when you have the power of
>> the VHDL language at your disposal in a VHDL testbench?  Now, if you
>> have vectors from an external model/simulation, those can be applied
>> with text-io relatively easily from within a vhdl testbench that will
>> run on any vhdl simulator.
>>
>> My "unit level tests" are usually at a high enough level that I need a
>> lot more capability than is available in any vector based scripting
>> language.
>>
>> Andy
> 



Article: 111359
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:21:34 GMT
Links: << >>  << T >>  << A >>

"Ben Jones" <ben.jones@xilinx.com> wrote in message 
news:eia1b7$dfm1@cnn.xsj.xilinx.com...
>
> "KJ" <Kevin.Jennings@Unisys.com> wrote in message 
> news:1162320665.907686.101530@h48g2000cwc.googlegroups.com...
>>
>> Ben Jones wrote:
>>
>>> There are many problems
>>> with wizards and core generators for things like RAMs and arithmetic
>>> elements - mostly, they are the wrong level of abstraction for most 
>>> designs.
>>
>> Maybe.  I find there lack of a standard on the 'internal' side to be
>> the bigger issue.
>
> For the smaller "building block" components, I'd say that's not much of an 
> issue at all. After all, how many different interfaces can you think of 
> for an accumulator or shift register? Most of the differences between 
> vendors seem to be superficial (e.g. naming) at that level. The problem I 
> have with these low-level blocks is that they go against the basic 
> principle of abstraction; instead of hiding complex functions behind 
> simple interfaces, they do the exact opposite. And they hold back 
> designers by perpetuating the "TTL 7400" design mentality.
No, I'm thinking of bigger blocks...the things you wouldn't want to have to 
write the code for because it is just a sub-function of the overall design. 
Bridges to SDRAM, DDR, PCI, compression, image processing and security 
algorithms.  Not your simple TTL type of stuff.

>
>>> they help designers get the most out of the silicon in those cases where
>>> synthesis tools are not sophisticated enough to produce optimal results.
>>
>> I don't believe that a unique entity
>> is required in order to produce the optimal silicon.  Once the
>> synthesis hits a standardized entity name it would know to stop and
>> pick up the targetted device's implementation.
>
> I think that would be great. Of course, vendors' in-house synthesis tools 
> are unlikely to support that kind of system except for portability between 
> their own device families.
Why not?  Once they see the standardized entity called 'ddr_controller' they 
would instantiate their own hard coded IP algorithm for talking to the 
bloody thing.  I'm not interested in re-inventing the wheel, just in reusing 
that wheel.

>> Tell me what prevents everyone from standardizing on an interface to
>> their components in a manner similar to what LPM attempts to do?  The
>> chip guys do it for their parts, the FPGA vendors don't seem to want to
>> do anything similar on the IP core side.
>
> I don't think anything prevents it, other than whatever all-pervading 
> force there is in the universe which prevents people from agreeing about 
> things. :-)
But it's not really an all-pervading force.  If it were we wouldn't have any 
standards like PCI, I2C, PCI Express, DDR....on and on and on.  So where is 
the list of interface standards for inside the chip?  Wishbone is about it 
for FPGAs...and it needs some work but it's not bad.  So do the big guys all 
support Wishbone?  Build it into their system design tools? 
Ummmm....well....no....what do they support?  Well, here is the Brand A 
'standard', brand X standard etc.
>
> The OpenFPGA initiative have a working group on core interfacing. There's 
> LPM (obsolete IMHO). There's OCP. There's no shortage of people proposing 
> ideas for standard interfaces, but there is a shortage of time, money and 
> energy to do anything about it. I think you'll find most engineers in 
> favour of standardization to some extent, but there's no one single 
> driving force for adoption. Some people also see it as a barrier to 
> innovation. (It isn't, but still, some people see it that way.)
I agree

>
>> Can you list any 'standard' function IP where the code can be portable
>> and in fact is portable across FPGA vendors without touching the code?
>
> No. But I'm willing to bet that any engineer worth their salt would be 
> able to write the appropriate glue logic to convert one to the other 
> without working up a sweat.
And I'll bet that any engineer worth their salt would also rather not keep 
re-inventing the wheel and doing needless bus translators.

>
> In some cases, for example if a customer is using a processor-based system 
> design environment such as Platform Studio (X) or SOPC builder (A), the 
> "proprietary" interface to (say) a DDR SDRAM controller is hidden away, to 
> a great extent, because the tools provide a system-level abstraction.
Yes, they all have their own way of making our lives 'easier'....in their 
minds at least.

>
> Here's another thought - in many industries (e.g. consumer electronics and 
> eletricals) the quality of the interface is a big differentiating factor 
> for the purchaser. Why shouldn't this be true for digital interfacing 
> standards too? A customer might have a preference for a CoreConnect-based 
> system over an AMBA-based system, or vice versa, based on which of the 
> interface's features are relevant to their needs.
Choosing a standard based on features and performance that are relevant is 
exactly the right thing.  That's not what you're basing your decision on 
between 'X' and 'A'.

KJ 



Article: 111360
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:26:07 GMT
Links: << >>  << T >>  << A >>

"Mike Treseler" <mike_treseler@comcast.net> wrote in message 
news:4qsa4oFoka7cU1@individual.net...
>
>>> Can you list any 'standard' function IP where the code can be portable
>>> and in fact is portable across FPGA vendors without touching the code?
>
> I can. A synch fifo using one read port and one
> write port from an inferred dpram.

But you didn't answer the question....reworded to 'What is the name of that 
standard IP'?  lpm_fifo is the only one that I can think of that fits your 
functional description.  Writing the function yourself (while you may want 
to do it anyway) does not qualify it as a 'standard'.  You write good code 
Mike, but not everything you write is ready to be called a standard ;)

KJ 



Article: 111361
Subject: Re: Interface standards (was Re: Dual Port RAM)
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:28:50 GMT
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:1162418508.842528.165280@k70g2000cwa.googlegroups.com...
> Ray Andraka gave the pertinent answer to your question. The rest of us
> meandered about...
> Peter

I was moseying not meandering....and apparently in the mood to spark a 
discussion

KJ 



Article: 111362
Subject: Re: Dual Port RAM
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:34:05 GMT
Links: << >>  << T >>  << A >>

"Martin Thompson" <martin.j.thompson@trw.com> wrote in message 
news:ulkmv8mwx.fsf@trw.com...
> "KJ" <Kevin.Jennings@Unisys.com> writes:
>
>
> More like it was an Altera-driven "standard" that Xilinx never
> supported, so it never got to be vendor independent.
>
But it is a standard issued by a recognized body.  But I've yet to hear what 
is soooo burdensome about LPM that it couldn't be supported...'specially 
since there aren't that many 'useful' functions in there to begin with.  And 
technically speaking I believe Xilinx 'does' support LPM, but from what I 
hear, not very well.

We should be way beyond standardizing on things as low level as the LPM 
stuff....but we're not....

KJ



Article: 111363
Subject: Re: Dual Port RAM
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 02 Nov 2006 04:36:52 GMT
Links: << >>  << T >>  << A >>

"Ray Andraka" <ray@andraka.com> wrote in message 
news:wXT1h.25863$v81.58@newsfe18.lga...
> KJ,
>
> This is actually a fairly common usage  model for the Xilinx dual port 
> RAMs. It lets you, for example store two words per clock on one port and 
> read them one word per clock on the opposite port at perhaps a faster 
> clock rate. The data width and address width vary inversely so that there 
> are always 18k or 16K bits in the memory (18K for the widths that
<snip>
I was misinterpreting the original post as wanting to independently vary 
address and data widths.  Bus resizing for various reasons has many 
applications, I agree.

KJ 



Article: 111364
Subject: Re: Dual Port RAM
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 1 Nov 2006 20:39:35 -0800
Links: << >>  << T >>  << A >>
The issue is with hard-coded blocks.
Soft logic can be changed, manipulated, improved, reduced to your
heart's desire.
Hard-coded logis is the way it is.
If we implement a standard, that's it. Nobody can modify it without
seriously affecting performance.
If we had not implemented "first-word-fall-through" in the FIFO
controller,(we did), it would have been almost impossible to add,
without serious performance loss.
We do think about these things, but very often there is not "one
standard". And if you implement one way, the other method suffers.
These designs are not incremental, it is very easy to burn your
bridges.
And iti srather unlikely that brand A will pick exactly the same
size/speed/power/versatility trade-off that we at brand X do.
So much for standards. They come with their own bag of trade-offs,
usually reduced speed and increased complexity. Very easy to see in
memory-related circuits (like FIFOs). We had a self-imposed edict: It
has to work at 550 MHz, worst-case at the fastest speed grade.
Otherwise we went back to the drawing board. Same thing for the DSP
highly-glorified multiplier/accumulators.
If you add a 1-ns external gate to a 550 MHz design, the performance
drops to 355 MHz. Math is brutal. Very few people like that. Dedicated
logic is fast and small, patches are slow and big. That's life.
Peter Alfke

On Nov 1, 8:02 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "Peter Alfke" <a...@sbcglobal.net> wrote in messagenews:1162345630.497517.281500@h48g2000cwc.googlegroups.com...> KJ, You like standards.
> > We just finished implementing PCIexpress. When I look at the complexity
> > of that standard, I just cringe. I cannot fathom why one needs so much
> > stuff to communicate data. But then I am old frugal and basic guy who
> > believes in simplicity.But again, you're probably standards compliant on the physical pin side but
> what about on the 'other' side?  A communication's bridge exists because it
> connects TWO disparate interfaces, so what is the standard interface that is
> used internal to the FPGA that you're bridging over to PCIexpress?
>
> And I agree with you about frugality.  The 'internal to the chip' standard
> interface should be something robust yet something that when used in simple
> comm situations reduces down (via the magic of synthesis logic optomization)
> to something darn close to the bare minimum.  Certainly there are cases
> where anything over the bare minimum might be too much, but those tend to be
> exceptions (i.e. relatively small logic that can be hand optomized in the
> grand scheme of the entire FPGA design).
>
> > Talking about a FIFO, what other standard interface do you want, except
> > data-in, data-out, 2 clocks, 2 enables, 4 flags and perhaps a reset?
> > Isn't that about as generic as it can get? Why would Altera do it
> > differently, except that they don't have a hard-coded 550 MHz one...OK, let's discuss the fifo.  Specifically let's take the EIA standard
> lpm_fifo.  That entity defines the input for a hunk-o-code that implements a
> fifo.  If I instantiate an lpm_fifo and target that to the appropriate
> Xilinx part will I get that 550 MHz performance?  If so, then you've
> provided an example of where standardizing on the interface is a 'good'
> thing.  If not, then can you explain what is so burdensome about the entity
> definition of lpm_fifo that makes that 550 MHz unachievable?
>
> We're not talking about getting extra functionality, we're talking about
> getting the same function.  The synthesis operation, once it saw 'lpm_fifo'
> and targetting brand X could know that there is a hard coded thingy to
> implement it....that's what we pay the synthesis tool to do, right?
>
> Now granted the 'lpm_fifo' is not necessarily the best and grandest thing to
> talk about optomizing but you brought up the fifo.  Things like controllers
> come to mind as well (i.e. I2C, DDR, SDRAM, PCI, blah, blah, blah).  Many of
> these are really communication's bridges that hook two different busses
> together to exchange information.  One one side (the physical pin side) we
> have all the standards, on the other side...well...a bit lacking (IMO) in
> calling things a standard....and yet things like Wishbone or Avalon or what
> have you that were all thought through of as being an 'inside the chip' comm
> bus really do synthesize and logically optomize quite well.
>
> After getting over the worry (if there is any) about people jumping ship
> because their code could now be truly portable to brand A, B, C.... you
> should also recognize that it would also be a productivity improvement
> because it would improve code reuse and aid in simply division of labor
> because you wouldn't have these ad hoc, "let me pass you this signal it will
> happen two clock cycles before that" type of thing.
>
> Perhaps instead of bantering about specific examples that we each seem to
> think bolster our points you can give us the Xilinx view of
> - Standardized internal interfaces, good for business?  (Xilinx that is)
> - What standards work for these internal interfaces are you compliant with?
> - What push for improving these standards are you participating in?
>
> In my view this internal interface should scale well (i.e. not get
> burdensome in wasting logic resources in the synthesized design) if I want
> to use it inside a VHDL architecture to communicate between processes all
> the way up to it being an external interface (if I so choose).
>
> > I vote for smarter synthesis tool that interprete your intentions in
> > the best possible way.So do I.
> 
> KJ


Article: 111365
Subject: Re: Dual-port BlockRAM "write first" puzzler...
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 1 Nov 2006 20:51:16 -0800
Links: << >>  << T >>  << A >>
John, as I e-mailed you privately, the Virtex-5 user guide tells you
clearly "don't do that".
And that same reasoning also applies to the older parts.
The two write mechanisms in the two port controllers may be very
similar, but they are separate entities, and they may disagree in the
timing, pehaps only by picoseconds, but that's enough.
In order to do what you want to do, you have to stagger the clocks.
BTW: This problem only occurs when both ports use the same address, and
one of them writes.
Will the other port red the old or the new data? I am convinced that
this is really undefined.
You may be lucky and it works your way, but I would not bet on it.
Peter Alfke


On Nov 1, 6:22 pm, "JustJohn" <john.l.sm...@l-3com.com> wrote:
> The setup:
> Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write
> first" mode.
> Both ports have the same (global) clock and the same address, with
> Enable tied high,
> so they are both always reading.
>
> Part 1:
> Cycle 0- (init value) WE to port A, with DI = 0.
> Cycle 1- (change value) WE to port A, with DI = 1.
> Cycle 2- (cycle 1 results) Output A is 1 because it is in write first
> mode and 1 was written in cycle 1.
> What is value at output B during cycle 2?
>  a) 0 because port B is not being written to, and reflects the value it
> would have read if there was no activity on port A.
>  b) 1 because port A is in write first mode, and the activity on port A
> interferes with port B.
>  c) x Don't do this, the result is indeterminate.
>
> Part 2: same as part 1, with A and B switched
> Cycle 0- (init value) WE to port B, with DI = 0.
> Cycle 1- (change value) WE to port B, with DI = 1.
> Cycle 2- Value at output B is 1 because it is in write first mode and 1
> was written in cycle 1.
> What is the value at output A during cycle 2?
>  a) 0 ...
>  b) 1 ...
>  c) x ... I said don't do this!!!
>
> I'm hoping the answer to both Part 1 and Part 2 is a), because it
> simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates
> muxes and registers external to the RAM, and this is going into an
> already very tight design).
>
> Peter tells me c) for both (I think).
>
> Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a
> result of b) for Part 1, and a result of a) for Part 2.
>
> My first instinct is to trust Peter, but the fact that the XST user
> guide gives deterministic code gives me pause.
>
> So I put it to the group, hoping someone has actually used this setup
> and has some definite answer.
> I'm a day away from coding up a test circuit to find out what the
> silicon really does, but if anyone knows of anyplace where operation in
> this scenario might be documented, it would save me a few hours.
> Thanks all,
> Just John


Article: 111366
Subject: Re: Need flash adc with plcc format?
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 2 Nov 2006 06:19:38 -0000
Links: << >>  << T >>  << A >>
"Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message 
news:eibouj$d3i$1@news.ks.uiuc.edu...
> Is there a good reference for the types of IC packages and their effects 
> on SI?
>
>
> ---Matthew Hicks
>
>
Hi Matthew,
The Amkor website is somewhere to start. For example compare and contrast 
these two packages:-

http://www.amkor.com/Products/all_datasheets/MicroLeadframe.pdf

and

http://www.amkor.com/Products/all_datasheets/plcc.pdf

MLF12 lead inductance ~0.6nH   capacitance ~0.2pF

PLCC20  lead inductance ~2nH   capacitance ~0.6pF

HTH, Syms. 



Article: 111367
Subject: Re: Dual-port BlockRAM "write first" puzzler...
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 1 Nov 2006 22:33:00 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> John, as I e-mailed you privately, the Virtex-5 user guide tells you
> clearly "don't do that".

Sorry for my mis-understanding Peter, You said look at the V5 docs, and
I didn't. I'll take more time before going to the group next time.

> And that same reasoning also applies to the older parts.
> The two write mechanisms in the two port controllers may be very
> similar, but they are separate entities, and they may disagree in the
> timing, pehaps only by picoseconds, but that's enough.
> In order to do what you want to do, you have to stagger the clocks.

Not possible in this case, the operation has to be symmetric on both
ports.

> BTW: This problem only occurs when both ports use the same address, and
> one of them writes.

Yes sir, got that. It turns out that I can re-arrange access ordering
to keep the addresses different, operate both ports in read first mode,
use the En pins instead of tying them high, still avoid the external
muxes/registers, keep the same latency/throughput, and the only
overhead is the logic to drive the En pin (<1%). Your comments led me
to this solution, thank you!

> Will the other port red the old or the new data? I am convinced that
> this is really undefined.
> You may be lucky and it works your way, but I would not bet on it.
> Peter Alfke
>

What threw me was that the XST DPRAM inference code simulated
predictably, in a manner that was inconsistent with the actual
circuitry. The whole point of synthesis from simulated code is that the
results match. This is one of those cases where they don't. Rare, but
it happens.

Thanks again for your time, and for bumping me back onto the right
path.

John L. Smith

>
> On Nov 1, 6:22 pm, "JustJohn" <john.l.sm...@l-3com.com> wrote:
> > The setup:
> > Virtex ( >= 2 ) Dual-port BlockRAM configured with both ports in "Write
> > first" mode.
> > Both ports have the same (global) clock and the same address, with
> > Enable tied high,
> > so they are both always reading.
> >
> > Part 1:
> > Cycle 0- (init value) WE to port A, with DI = 0.
> > Cycle 1- (change value) WE to port A, with DI = 1.
> > Cycle 2- (cycle 1 results) Output A is 1 because it is in write first
> > mode and 1 was written in cycle 1.
> > What is value at output B during cycle 2?
> >  a) 0 because port B is not being written to, and reflects the value it
> > would have read if there was no activity on port A.
> >  b) 1 because port A is in write first mode, and the activity on port A
> > interferes with port B.
> >  c) x Don't do this, the result is indeterminate.
> >
> > Part 2: same as part 1, with A and B switched
> > Cycle 0- (init value) WE to port B, with DI = 0.
> > Cycle 1- (change value) WE to port B, with DI = 1.
> > Cycle 2- Value at output B is 1 because it is in write first mode and 1
> > was written in cycle 1.
> > What is the value at output A during cycle 2?
> >  a) 0 ...
> >  b) 1 ...
> >  c) x ... I said don't do this!!!
> >
> > I'm hoping the answer to both Part 1 and Part 2 is a), because it
> > simplifies a 2-D 5x5 Gaussian filter I'm putting together (eliminates
> > muxes and registers external to the RAM, and this is going into an
> > already very tight design).
> >
> > Peter tells me c) for both (I think).
> >
> > Meanwhile, XST user guide gives DPRAM inferring VHDL which sims a
> > result of b) for Part 1, and a result of a) for Part 2.
> >
> > My first instinct is to trust Peter, but the fact that the XST user
> > guide gives deterministic code gives me pause.
> >
> > So I put it to the group, hoping someone has actually used this setup
> > and has some definite answer.
> > I'm a day away from coding up a test circuit to find out what the
> > silicon really does, but if anyone knows of anyplace where operation in
> > this scenario might be documented, it would save me a few hours.
> > Thanks all,
> > Just John


Article: 111368
Subject: Re: A pre-emptive strike against blaming the chip
From: "Ron N." <rhnlogic@yahoo.com>
Date: 1 Nov 2006 23:24:54 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> There is a difference, 60 years ago, a curious kid could at least try
> to understand the world around him/her.
> Clocks, carburators, telephones, radios, typewriters, etc.

In a talk at the Computer History Museum that Gordon Moore
gave on the history of Moore's Law, he was asked about what
influenced his interest in science.  His answer included playing
with chemistry sets and blowing things up.

He was later asked about the some of reasons for the decline
in US science education.  His answer was that nowadays kids
couldn't buy "real" chemistry set and blow things up.


IMHO. YMMV.
-- 
rhn A.T nicholson d.0.t C-o-M


Article: 111369
Subject: Re: DSP48 carry logic for multi-precision addition
From: "Tim" <gueneysu@crypto.rub.de>
Date: 2 Nov 2006 00:14:39 -0800
Links: << >>  << T >>  << A >>
Thanks for your response, Peter! My favorite carry handling would be a
solution with which I don't need to leave the dedicated silicon to save
on additional register (and latency) stages which would be necessary to
keep the high frequency constraint (500MHz). Additional latency would
delay the next computation of a 32bit chunk significantly demanding for
a much higher cycle count for the entire 256bit addition.
Do you have a good idea how I can pass on the 33rd carry bit (or upper
bit if sign extended) between the computations and DSP slices without
using the fabric? It would be so easy, if the P[47]/PCIN[47] carry
logic wouldn't be inverted...but an inverted carry is probably quite
useless for my desire.

BTW: what is the reason for the inverted P[47] carry logic?

Thanks again ;-)
Tim


Peter Alfke schrieb:

> If you are adding 32 bits, can't you just use the next higher sum bit
> as carry?
> Maybe that's too obvious...
> Peter Alfke
>
> On Oct 31, 1:13 am, "Tim" <guene...@crypto.rub.de> wrote:
> > Hi there,
> >
> > I am working on a high-speed (500 MHz, Virtex 4, speedgrade -12) and
> > multi-precision adder (unsigned) capable to compute 256 bit additions
> > using the DSP48 slices. I am using a sequential adder design, thus
> > passing a chunk with the lowest bits to a DSP adder slice fist (each
> > chunk is only 32 bit for internal reasons), continuing up to the
> > highest bits of the input computing a 32 bit result each clock. When
> > implementing the carry logic between the chunks, I just came across
> > with its funny realization in the DSP slice. You can either use the
> > fabric to determine the carry yourself (1) or use the inverted MSB from
> > the output P[47]/PCIN[47] (2). Using the fabric (1) for carry
> > implementation requires the additional CARRY_IN register to preserve
> > the maximum clocking speed of 500MHz making it necessary to wait for
> > the carry until the computation of the next chunk can start. Option (2)
> > seems not to be applicable to my problem due to the inverted carry
> > signal which is useless for my scenario. Does anybody have a good
> > solution to this?
> > 
> > Thanks already in advance!
> > Cheers, Tim


Article: 111370
Subject: Re: Rad-hard (neutron/SEU and space) tutorial?
From: "Thomas Stanka" <usenet_10@stanka-web.de>
Date: 2 Nov 2006 00:44:23 -0800
Links: << >>  << T >>  << A >>
Hi,

MikeD schrieb:
> Does anyone know of something more like a "how to" or real design
> guidelines for designing rad-hard systems, for system/board-level (ADC,
> DAC, power supplies, etc) design, as well as for FPGA and ASIC
> hardware?

For systemlevel actually no free available howtos, sorry. For
FPGA/ASIC, you get information on the websites of the vendors.

> were saying.  I know that for an FPGA, I should either use a flash or
> antifuse based chip, or otherwise use a chip with configuration CRC

You will typically have a client, when developing a radhard circuit.
First read the requirements   from your client. It's a big difference,
if your circuit is designed for a mission on Mars or  if you need to
build equipment intended to be active for 15 years in GEO. In general
it could be said, that only fuse based fpgas are acceptable for the
second scenario, while you could achieve the first with nearly every
fpga.
The easiest way to achieve a rad hard fpga design is by using an Actel
RT device with a "normal" rtl code. Your design should be bullet proof
against deadlocks occuring due to any SEU, which is a good advice for
every design, but a necessary condition to sell a rad hard device.

> checking and reloading, but how do I select parts like power supplies,
> ADC/DACs, and RAMs?  Even if my FPGA or ASIC design is solid, I'm
> worried that I'm going to end up shooting myself in the foot on the
> rest of the system.

Again depending on your requirements. Do you need only to be rad-hard
against a total dose? Then search devices with given total dose and
check wheter this device matches the required total dose. Do you need
to be stable against SEE? Thats a bit harder.
If you purchase rad-hard devices, you will get a lot of information
regarding behavior of this device under radiation. You have to read,
understand and verify, that your system accepts this behavior for each
devices. E.g a OPAmp might have a transient after hit from a heavy ion,
if this opamp feeds your reset circuitry, than you have to deal with
this transient by:
1. selling it as a feature
2. removing any unintended influence of this transient

Your client will likely accept a shortterm loss of data, but can't
accept a loss of equipment.
 
bye Thomas


Article: 111371
Subject: Xilinx ISE Webpack - Any usable simulator for the Linux platform ?
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Date: Thu, 02 Nov 2006 10:07:46 +0100
Links: << >>  << T >>  << A >>
Hi everybody,

I need to simulate VHDL code using the ISE 8.2i Webpack on Linux. After some
investigation, I found out that two simulators were available:

- ModelSim, which I have some experience with, would cover all my needs, but
the ModelSim Xilinx Starter edition only runs under Windows.

- ISE Simulator, which is pretty much unusable from what I've seen so far.
The simulation is not interactive (although I could live with that), but I
haven't been able to watch internal signal values. It seems only the entity
ports can be displayed, which makes debugging much more difficult.

Is there any proper simulation solution for the Linux platform ? I know
ModelSim has a Linux version, but that's way too expensive for personal
projects. Is there any way to run ModelSim Xilinx Starter edition under
Linux ? I tried running it in Wine, but it complained about not being able
to checkout a valid license, even though the flexlm diagnosis tool reports
no problem at all.

Any help would be appreciated. Developing VHDL code without a simulator is
near to impossible.

Best regards,

Laurent Pinchart


Article: 111372
Subject: Re: Xilinx ISE Webpack - Any usable simulator for the Linux platform
From: antonio bergnoli <bergnoli@pd.infn.it>
Date: Thu, 02 Nov 2006 10:32:31 +0100
Links: << >>  << T >>  << A >>
I am very happy with ghdl, i almost use only that. Also for the post 
trans/map/p&r simulations.


Laurent Pinchart ha scritto:
> Hi everybody,
> 
> I need to simulate VHDL code using the ISE 8.2i Webpack on Linux. After some
> investigation, I found out that two simulators were available:
> 
> - ModelSim, which I have some experience with, would cover all my needs, but
> the ModelSim Xilinx Starter edition only runs under Windows.
> 
> - ISE Simulator, which is pretty much unusable from what I've seen so far.
> The simulation is not interactive (although I could live with that), but I
> haven't been able to watch internal signal values. It seems only the entity
> ports can be displayed, which makes debugging much more difficult.
> 
> Is there any proper simulation solution for the Linux platform ? I know
> ModelSim has a Linux version, but that's way too expensive for personal
> projects. Is there any way to run ModelSim Xilinx Starter edition under
> Linux ? I tried running it in Wine, but it complained about not being able
> to checkout a valid license, even though the flexlm diagnosis tool reports
> no problem at all.
> 
> Any help would be appreciated. Developing VHDL code without a simulator is
> near to impossible.
> 
> Best regards,
> 
> Laurent Pinchart
> 

Article: 111373
Subject: Re: Spectre of Metastability Update
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 02 Nov 2006 09:36:17 +0000
Links: << >>  << T >>  << A >>
On Thu, 02 Nov 2006 03:26:14 GMT, "KJ" 
<kkjennings@sbcglobal.net> wrote:

>"Peter Alfke" <peter@xilinx.com> wrote in message 
>news:1162418895.253069.240680@f16g2000cwb.googlegroups.com...
>>I remember the birth of the 22V10 (it's an AMD product, not MMI's)
>> It had the gestation period of an elephant, and it almost killed the
>> design engineers. Too complicated...
>> Times have changed.
>> Peter Alfke
>
>Yes, those 'V' parts were pretty versatile (hence the 'V' in 16V8, 22V10) 
>for those of us around at the birth of the 16R4, 16R6 and 16R8 when great 
>thought had to be applied to decide whether an output should be clocked or 
>combinatorial...and if you got it wrong you had to rewire the circuit board 
>to move it to the appropriate pin....well, that and having to remove and 
>pitch the part because it was fuse based one time programmable.
>
>KJ...feeling ooooooold now....where's my hot cocoa? 

Does he take sugar?  Me too.  The olde original PAL assembler was
in FORTRAN, and MMI would give away the source code - it was only
a few hundred lines of code, back in the days when PAL16R8s were
high-tech.  Two separate FORTRAN programs, one for the 20-pin
and one for the 24-pin parts.  I remember fixing a bug in the 24-pin
version, but sadly I've lost all those old 9-track magtapes with the
files on them...  My VAX DCL script to drive the Data I/O device
programmer was almost as long as the PAL assembler!

As Ray said, those PALs revolutionized what we could do - as an 
engineer working for a struggling startup, I couldn't believe my luck.

The amazing thing is that we engineers have gone on being
at least that lucky, consistently, for the 25 years since then.

Betcha the source code for ISE don't fit in a single ring binder,
though :-)
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 111374
Subject: Re: Dual Port RAM
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 02 Nov 2006 09:58:49 +0000
Links: << >>  << T >>  << A >>
"KJ" <kkjennings@sbcglobal.net> writes:

> "Martin Thompson" <martin.j.thompson@trw.com> wrote in message 
> news:ulkmv8mwx.fsf@trw.com...
> > "KJ" <Kevin.Jennings@Unisys.com> writes:
> >
> >
> > More like it was an Altera-driven "standard" that Xilinx never
> > supported, so it never got to be vendor independent.
> >
> But it is a standard issued by a recognized body.  But I've yet to hear what 
> is soooo burdensome about LPM that it couldn't be supported...'specially 
> since there aren't that many 'useful' functions in there to begin
> with.  

That's true - my *impression* at the time (which was around 2000) was
that Xilinx didn't want to make migration between vendors too easy.
That's just my impression mind, I don't know what actually went on.
Based on what I read around the LPM website.

> And technically speaking I believe Xilinx 'does' support LPM, but
> from what I hear, not very well.
> 

That's interesting - any idea how?

> We should be way beyond standardizing on things as low level as the LPM 
> stuff....but we're not....
> 

In some ways we are - I've never instantiated an LPM_COUNTER, an
incrementing variable does the job for me :-)

Cheers,
Martin

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

   



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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