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 73700

Article: 73700
Subject: Re: How to design a programming parallel cable
From: gvaglia@gmail.com (Guido)
Date: 28 Sep 2004 09:10:36 -0700
Links: << >>  << T >>  << A >>
Thanks to both of you for the reply but as I'm working with a
university, in order to order some components I need an estimate and
moreover the university can pay with bank transfer only 30 days after
the recipt of the goods...so I don't think that i can buy on xilinx
web site.
Guido

"Alex Gibson" <me@privacy.net> wrote in message news:<2rngkvF1chsfiU1@uni-berlin.de>...
> "Jon Beniston" <jon@beniston.com> wrote in message 
> news:e87b9ce8.0409231030.326d0b2a@posting.google.com...
> > gvaglia@gmail.com (Guido) wrote in message 
> > news:<44f5f440.0409230231.4e64da8c@posting.google.com>...
> >> Hi all!
> >> My Xilinx Parallel Cable IV was lost during a travel and it needs 5
> >> weeks to receive another from Memec.
> >
> > You can order one from Xilinx's web site. They ship internationally.
> > They got me mine in a couple of days.
> >
> > Cheers,
> > JonB
> 
> Xilinx's shipping is very good (who ever they use).
> Ordered on a tuesday night recieved the order on the thursday morning.
> Not bad from the US to Sydney, Australia.
> 
> Alex

Article: 73701
Subject: XST Tool - Want a verilog simulation netlist
From: varunjindal@yahoo.com (Varun Jindal)
Date: 28 Sep 2004 09:21:13 -0700
Links: << >>  << T >>  << A >>
Hello,

I want to compare two designs, one of which is written in verilog
while the other one is in vhdl. the testcases are also written in
verilog. while running the vhdl design, (using XST VHDL) .. the design
compiles without error, but i couldnt figure out a way to generate the
simulation netlist in verilog for the design. does there exist any
such switch using which i can generate a verilog simulation netlist
for designs compiled with XST VHDL

thanks in advance.,

regards
Varun Jindal.

Article: 73702
Subject: Re: fast adder and equal
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 28 Sep 2004 09:33:27 -0700
Links: << >>  << T >>  << A >>
Rune,
Have you run the timing analyser to find out which path is failing? The
'(Levels of Logic = 9)' implies that it's not the carry chain, which, for a
28 bit counter, would be about 14 levels, 2 bits/level. I suggest you run
the analyser and post your failing path.
Cheers, Syms.
"Rune Christensen" <rune.christensen@adslhome.dk> wrote in message
news:41596bb8$0$257$edfadb0f@dread12.news.tele.dk...
>
>
> I have already done that but my goal is 8 ns and a simple implementation
> gives
>
> Slack:                  -1.380ns (requirement - (data path - clock path
skew
> + uncertainty))
>   Source:               cnt_0 (FF)
>   Destination:          cnt_3 (FF)
>   Requirement:          8.000ns
>   Data Path Delay:      9.373ns (Levels of Logic = 9)
>   Clock Path Skew:      -0.007ns
>   Source Clock:         clk_BUFGP rising at 0.000ns
>   Destination Clock:    clk_BUFGP rising at 8.000ns
>   Clock Uncertainty:    0.000ns
>



Article: 73703
Subject: Boot : Sram Problem
From: "Johann Waldherr" <jwa@mediornet.com>
Date: Tue, 28 Sep 2004 09:40:42 -0700
Links: << >>  << T >>  << A >>
I am working on a Xilinx V2P4 FPGA design with an PLB EMC. I can execute programs from 16bit wide SRAM when they are downloaded with Xilinx's XMD.
Now i wrote a bram bootstrap loader that copies a fw image from flash into sram and then jumps to it.

the STRANGE thing is that this jump most often does not work at all. the powerpc stalls at location 0xffff0700. a jump instruction seems to cause the problem.

has anybody ideas how to solve our problem? how can we detect the source problem?

regards
-hans

Article: 73704
Subject: Co-Processor for Microblaze or PowerPC Processor
From: "Roger Planger" <ernte23@gmx.at>
Date: Tue, 28 Sep 2004 17:54:34 +0100
Links: << >>  << T >>  << A >>
Hi

I am currently developing a Co Processor which performs some arithmetic 
operations more efficiently, and I want to test this within a processor. I 
have done this once with den LEON Processor, but now I wanna try it with 
Microblaze or Power PC Processor if this is possible. I use VHDL as design 
language, so is there some online tutorial which explains me how I can add 
my Co Processor and the new op-Codes which should be performed by the 
Coprocessor. Unfortunately I wasnt able to find any information about this 
on the web

Cheers
Roger 



Article: 73705
Subject: Re: NV on-chip memory?
From: guys@altera.com (Guy)
Date: 28 Sep 2004 10:10:37 -0700
Links: << >>  << T >>  << A >>
Let me first say thank you for your responses.
To address some of the questions / comments:
I realize that not everyone will extract the same application or value
from the on-chip NV memory, however, since it has the potential to
provide or support different applications, general enough value may be
justified for inclusion.
Answers / Comments for Jim and Hal: 
a.  bad bits:  built in ECC would make bad bit transparant to the user

b.  speed = assume approximately 25ns access time

c.  width = flexible, 16/32/64 bit

d.  secure code storage would come by two assumptions:  i) on-chip
processor preventing external need to access the memory. ii) readback
via JTAG etc of Memory would be programmed as disabled by the user

e.  on-chip charge pumps require no special external voltage supply

f.  user application would be able to log/write data to NV memory for
storage

g.  external applications could read NV data too, but you obviously
loose security

h.  OTP = nonerasable

i.  no tradeoff with NV and Ram like functionality - it would be a
standard feature, not swappable block within the silicon family

j.  yes for non secure, it would enable integration into the FPGA of
on-board NV data for some applications (mature s/w code for example). 
Realize that also for some applications, you can create a sense of
"virtual" unlimited multiwrite capability.  To demonstrate what I mean
by Virtual multi-write, I'll use the following example.  Let's say
that you know you may need to write 10,000 maximum lifetime events at
100 bits data each but do not need to keep history for more than 16
events.  As a designer, you could buy a tiny block of flash or EEPROM
of 1.6kbits and keep writing over the older events.  Or, with OTP, you
could simply purchase enough OTP memory to store the entire lifetime
worth of events.  Many applications that store NV data can quantify
the lifetime of storage from a practical specification.  One example,
Televisions need to store user configuration (like:  color, tint,
favorite channels etc), and need to provide the user with unlimited
adjustments of this data.  However if you make some assumption, the
design can calculate an upper limit of needed storage.  For example,
lets say 512bits stored, TV life is 20 years.  I would venture to
guess that if you assumed that data storage would occur Max once a day
for each of 20 years, you would be happy to remove the $1 EEPROM from
the board as long as the on-chip cost of the NV block was less. 
20yr*512b*365days = 7Mbit total


Any other creative thoughts on how this could be used would be
appreciated.

Thanks.

Message 2 in thread 
From: Jim Granville (no.spam@designtools.co.nz)
Subject: Re: NV on-chip memory? 
 
  
View this article only 
Newsgroups: comp.arch.fpga
Date: 2004-09-27 21:56:28 PST 
 

Guy wrote:
> quick survey...
> 
> Would it be of value to provide cheap on-chip one time programmable
> memory in an FPGA like Cyclone II?

Yes.

> Say 1-10Mbit depending on density.
> 
> It would be field or user programmable either via a programmer (very
> fast) or by user logic.

Can you clarify - would this need Supra Voltages/Currents, or
can the FPGA program itself, while running. ( eg could an
NV event log be created ? )


> It would be very secure (anti-copy) for:
>  secure s/w code with on-chip processor
>  secure data storage
>  configuration data(s) 
>  etc.
> 
> Please share your thoughts on the value (I would pay X% premium) and
> the type of ways you would use it?

First one is easy, X = 0  :)

> 
> Thanks in advance

JIM GRANVILLE POSTED:
An interesting question.

 From a wider industry perspective, there is a trend in the 
Microcontroller sector, to offer MASK devices, where a couple of
years ago the party line was 'we will now only make FLASH'.

  This must be driven by a number of factors, and clearly customer
demand, because of
** MASK is always going to be lower cost (fewer process steps, and
testing)
** Zero risk of field bit erasure
** No programming needed at customer end.
** Some apps stipulate that high voltage must be needed for program,
    so they want to _guarantee_ errant software cannot jump into the
    FLASH loader Block erase routines, for example :)

  Designers love Flash, because they can change it easily, but there
are many products that are code-stable, and the bean-counters prefer
the lowest cost options.

  So, back to your Cheap OTP memory in FPGA question ?

  First step would be to give every device a 128 bit unique ID, that
could be used for seed, and ID usage.
  Users would access that 'for free' in their present flows.

  Next step is more questions :
What is the yield of this memory ? All OTP memory has failures, so
what does the user do, if this occurs - remove the FPGA from a
expensive
PCB ?

Speed and Width of the memory ?

Can it be easily swapped for (say) off chip NV memory, or on Chip RAM
?

  Market Model here is then the same as for MASK uC.
Product development is using NV memory, and when proven stable,
the lower price option is chosen.
  This applies to both CODE and FPGA CONFIG memory spaces.

  For configuration data, I would guess the cost of this memory
would start to be significant, which would push up the device
variant price, and impact those users who never used this feature.

  I would imagine, provided it was easy to develop with, that
OTP memory would expand the usage of the simplest soft processors,
for state engines, and stable-code layers.

  Quite small OTP memory could be usefull here, << 1MBit, which
should have minimal impact on device cost ?

-jg
Post a follow-

hmurray@suespammers.org (Hal Murray) wrote in message news:<eMWdnbmEWOAXbsXcRVn-pQ@megapath.net>...
> >It would be very secure (anti-copy) for:
> > secure s/w code with on-chip processor
> > secure data storage
> > configuration data(s) 
> 
> I'm missing something.  How can data be both secure and
> useful?  If I can read it back out to use it, clearly the bad guy
> can too.  It might take him a while to write some code to get it.
> That doesn't seem like a big deal compared to the recent discusions
> on extracting the encryption key for the configuration bit stream.
> 
> Same general idea for secure code.  You might be able to make
> that secure if you had a dedicated memory that was only good
> for code.  But that seems against the general idea of flexibility
> that makes FPGAs so interesting.  Besides, it would probably be
> a pain to debug - or the debugging tools could be used to
> read the code memory.
> 
> 
> One time secure configuration data might be interesting.
> I'm not sure how much I would pay for it.  Not much for
> anything I can think of right now.

Article: 73706
Subject: Re: XST Tool - Want a verilog simulation netlist
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Tue, 28 Sep 2004 13:19:33 -0400
Links: << >>  << T >>  << A >>
On Tue, 28 Sep 2004 09:21:13 -0700, Varun Jindal wrote:

> Hello,
> 
> I want to compare two designs, one of which is written in verilog
> while the other one is in vhdl. the testcases are also written in
> verilog. while running the vhdl design, (using XST VHDL) .. the design
> compiles without error, but i couldnt figure out a way to generate the
> simulation netlist in verilog for the design. does there exist any
> such switch using which i can generate a verilog simulation netlist
> for designs compiled with XST VHDL
> 
> thanks in advance.,
> 
> regards
> Varun Jindal.

ngd2ver converts the ngd file to verilog
ngd2vhdl converts the ngd file to VHDL

You don't need to synthesize the designs to simulate them together, any
decent simulator like NCverilog can simulate Verilog and VHDL together.
Take the two sources and put them in the same testbench with some
comparison logic.


Article: 73707
Subject: Re: NV on-chip memory?
From: nweaver@soda.csua.berkeley.edu (Nicholas Weaver)
Date: Tue, 28 Sep 2004 17:35:21 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <a11322d6.0409271941.e71e499@posting.google.com>,
Guy <guys@altera.com> wrote:
>quick survey...
>
>Would it be of value to provide cheap on-chip one time programmable
>memory in an FPGA like Cyclone II?
>Say 1-10Mbit depending on density.

Would it slow down the fab or up the cost?

>It would be field or user programmable either via a programmer (very
>fast) or by user logic.
>
>It would be very secure (anti-copy) for:
> secure s/w code with on-chip processor
> secure data storage
> configuration data(s) 
> etc.

There is already a more secure mechanism for this: SRAM-based
encryption keys used to load encrypted bitfiles.  That mechanism can
be used to bootstrap a large non-volatile store, with a keystone of
the SRAM-based encyption key which is probably significantly harder to
reverse/crack than on-chip static bits.

Thus the "savings" by putting it on-chip are not security, but the
cost savings of not needing a large external Flash PROM.
-- 
Nicholas C. Weaver.  to reply email to "nweaver" at the domain
icsi.berkeley.edu

Article: 73708
Subject: Xilinx Read First Write First
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 28 Sep 2004 10:45:22 -0700
Links: << >>  << T >>  << A >>
What's this Read First or Write First on Xilinx BRAM about?



Article: 73709
Subject: Re: Xilinx Read First Write First
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 28 Sep 2004 17:56:58 GMT
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10lj8q5o44cr9f2@corp.supernews.com...
> What's this Read First or Write First on Xilinx BRAM about?


If you write to mem[addr] the same clock edge that you read mem[addr] on
that same port, what do you want for the result?

Do you want the old data before the write as if it were a register (read
first) or the brand new data that's in process of being written to the
memory array (write first)?  The Xilinx Software Manuals (library guide)
have the tables that try to explain the nuances.



Article: 73710
Subject: Re: Xilinx Read First Write First
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 28 Sep 2004 11:11:48 -0700
Links: << >>  << T >>  << A >>
So, I'm reading and writing on the same clock.  I suppose if I wanted to do
this, maybe for speed, I would want the read to be the old data before the
write. Can't think of any reason I would want the new data going in. I
already have it.



Article: 73711
Subject: Re: fast adder and equal
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 28 Sep 2004 11:12:33 -0700
Links: << >>  << T >>  << A >>


Rune Christensen wrote:

> I need information about creating a fast adder (n = n + 1) 
 > and a fast equal  (a = b). (both 28 bit signals)

> I'm going to create a fast binary counter in a FPGA Spartan II

> Would it be faster to create several 4 bit LFSR and a converter to binary 
> than a normal binary counter?

> I need the binary output because it's a timestamp

For a timestamp, why can't you write out the value of the LFSR,
and decode it later at data analysis time?  The sequence is
predictable.

28 bits is a lot, though.  How about two smaller LFSR's, with
relatively prime cycle lengths.  A small lookup table would convert
each to a binary count, and then you can easily figure out the
actual count.

-- glen


Article: 73712
Subject: Xilinx FIFOs
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 28 Sep 2004 11:15:32 -0700
Links: << >>  << T >>  << A >>
Xilinx seems a little weak on FIFOs.  Before I switched over I was working
on Cypress chips and they had drop-in FIFOs with self-addressing and all the
flags (bells and whistles).  Is this true or have I just not discovered the
right  ap note yet?



Article: 73713
Subject: Re: Xilinx FIFOs
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 28 Sep 2004 18:24:35 GMT
Links: << >>  << T >>  << A >>
You can choose a XIlinx core for the FIFO or you can get a Virtex-4 with the
FIFO built into the BlockRAM.

"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10ljaiji17fpe9@corp.supernews.com...
> Xilinx seems a little weak on FIFOs.  Before I switched over I was working
> on Cypress chips and they had drop-in FIFOs with self-addressing and all
the
> flags (bells and whistles).  Is this true or have I just not discovered
the
> right  ap note yet?



Article: 73714
Subject: Re: Xilinx Read First Write First
From: "John_H" <johnhandwork@mail.com>
Date: Tue, 28 Sep 2004 18:27:38 GMT
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10ljabn8ca1e8f6@corp.supernews.com...
> So, I'm reading and writing on the same clock.  I suppose if I wanted to
do
> this, maybe for speed, I would want the read to be the old data before the
> write. Can't think of any reason I would want the new data going in. I
> already have it.

A fall-through FIFO is one example where the data going in might be needed
on the output.
If the memory is for storage of values, why not use the most recent value
with a write-first?

Fixed delay-lines are easy to implement with a single address with read
first.



Article: 73715
Subject: Re: Xilinx Read First Write First
From: "Symon" <symon_brewer@hotmail.com>
Date: Tue, 28 Sep 2004 11:28:05 -0700
Links: << >>  << T >>  << A >>
What about a FIFO? If it's empty, you want the first data in to appear right
away.
Cheers, Syms.
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10ljabn8ca1e8f6@corp.supernews.com...
> So, I'm reading and writing on the same clock.  I suppose if I wanted to
do
> this, maybe for speed, I would want the read to be the old data before the
> write. Can't think of any reason I would want the new data going in. I
> already have it.
>
>



Article: 73716
Subject: Re: Simple Counter in Verilog
From: Bassman59a@yahoo.com (Andy Peters)
Date: 28 Sep 2004 11:43:43 -0700
Links: << >>  << T >>  << A >>
Bob Perlman <bobsrefusebin@hotmail.com> wrote in message news:<p03hl0tj9t776u2i0jnrl02oecn5g7lqjv@4ax.com>...

> I wouldn't be too quick to dismiss Stuart Sutherland's reference
> guide.  I use the printed version all the time, and it's extremely
> handy.

Agreed, although it assumes that you know the language and need a
cheat-sheet.  Of course, that cheat-sheet comes in handy all the time!
 That's why it's always on top of the monitor or someplace else
nearby.

-a

Article: 73717
Subject: Re: Xilinx Read First Write First
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 28 Sep 2004 11:51:48 -0700
Links: << >>  << T >>  << A >>
Any Virtex BlockRAM always performs a "free" read operation whenever you do
a write.
The data appearing at the data output is either the data previously stored
at that location (and about to be oberwritten), or it is the data you are
just writing, or the data output does not change, keeps holding its old
value. You pick one of these three choices by configuration.

The Virtex-4 FIFO has an optional "fall-through" mode, where data written
into an empty FIFO immediately appears on the read output port.
Responding to a different thread: The Virtex-4 FIFO generate FULL and EMPTY
flags and ALMOST FULL and ALMOST EMPTY flags, all internally synchronized
(rising and falling edges) to the relevant clock domain. We just finished
testing asynchronous operation at 500 MHz read clock rate, with no error in
>10e14 "going empty" cycles.
Peter Alfke, Xilinx Applications

> From: "Symon" <symon_brewer@hotmail.com>
> Newsgroups: comp.arch.fpga
> Date: Tue, 28 Sep 2004 11:28:05 -0700
> Subject: Re: Xilinx Read First Write First
> 
> What about a FIFO? If it's empty, you want the first data in to appear right
> away.
> Cheers, Syms.
> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
> news:10ljabn8ca1e8f6@corp.supernews.com...
>> So, I'm reading and writing on the same clock.  I suppose if I wanted to
> do
>> this, maybe for speed, I would want the read to be the old data before the
>> write. Can't think of any reason I would want the new data going in. I
>> already have it.
>> 
>> 
> 
> 


Article: 73718
Subject: Re: Xilinx Read First Write First
From: Peter Alfke <peter@xilinx.com>
Date: Tue, 28 Sep 2004 11:58:22 -0700
Links: << >>  << T >>  << A >>
It's mainly for compatibility with the behavior of the first BlockRAMs.
Nobody suggests that you should use it in newer designs...
Peter Alfke

> From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
> Organization: Posted via Supernews, http://www.supernews.com
> Newsgroups: comp.arch.fpga
> Date: Tue, 28 Sep 2004 11:11:48 -0700
> Subject: Re: Xilinx Read First Write First
> 
> So, I'm reading and writing on the same clock.  I suppose if I wanted to do
> this, maybe for speed, I would want the read to be the old data before the
> write. Can't think of any reason I would want the new data going in. I
> already have it.
> 
>It's for  


Article: 73719
Subject: Re: Spartan-3 VCCIO ramp up time
From: rickman <spamgoeshere4@yahoo.com>
Date: Tue, 28 Sep 2004 15:27:55 -0400
Links: << >>  << T >>  << A >>
Brian Davis wrote:
> 
> Steven Knapp wrote:
> >
> > The limitation is if ...
> >
> > * The VCCO supply ramps faster than the minimum
> > data sheet specification (Tcco)
> >
>  One question: is this strictly a power-up issue, or can it be
> triggered during operation?
> 
>  In particular, since the ramp spec. is worse for the leaded
> packages, could a large transient on the VCCO supply cause
> the same problem?
> 
>   e.g., if you configure a PQ208 with many parallel DCI
> terminations, at the end of configuration the VCCO supply will
> jump instantly from quiescent to full power ( maybe ~3 amps max.
> for a PQ208, but by that point you'd have heatsinking problems )

I don't think this is a problem.  The ramp speed issue in only of
concern at a voltage threshold around 0.8~1.0 volts.  As it was
explained to me, when the part powers up, there are a lot of transistors
which are turned on initially.  Once Vcc gets above about 1.0 volts,
everything is biased and the transistors that need to be off are off. 
But the part draws a lot of current in the meantime as the voltage
ramps.  If the voltage ramps too fast, the PS can max out on current and
for some reason, this will disturb the part and it will not initialize
correctly to the point that a power down must be done to correct the
problem.  

So the problem is that you must let the part draw as much current as it
needs as the voltage ramps up.  The spec is to let you know how much
current you will need for a given ramp rate.  Keep the ramp rate slower
than the worst case spec and the part will be happy with the current
spec'd in the data sheet.  After the voltage rises above about 1.0 volts
this is no longer an issue regardless of how the spec is written (or
interpreted).  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 73720
Subject: Re: MicroBlaze & SRAM
From: Philip Freidin <philip@fliptronics.com>
Date: Tue, 28 Sep 2004 19:31:15 GMT
Links: << >>  << T >>  << A >>
I wonder how you have connected the SRAM to microblaze?

In particular please describe the low order bits of the address
bus from the processor, and the low order address bits of the
SRAM.

I am guessing you have CPU addr bit 0 to SRAM addr bit 0.
This is not correct.

On Tue, 28 Sep 2004 11:02:30 +0100, Ben G <nospam@nospam.nospam> wrote:
>I had tried using a char pointer as you suggested but the values I want 
>to write out are 32 bit integers

If you only do word (4 byte) reads and writes, you probably
need something like this:

Address pins
CPU	SRAM
0	no connection
1	no connection
2	0
3	1
4	2
etc.

If you need byte reads and writes, then your SRAM must support
this, and you use the CPU address bits 0 and 1 to select the byte.

Philip

>when I use a char pointer the correct value is not written to SRAM.

Because the C compiler probably generated a byte write, not a word write

>Mem[80F0007E]=126
>
>Mem[80F0007F]=127

Neither xxxx7E or xxxx7F are word addresses. Word addresses always have
the lower 2 bits set to 0, and are not used, as per the description I
gave above.


>If I use a pointer but set the addresses manually as below it works. I 
>set the value of i to a large integer value and then increment it for 
>each location but set the address directly in the code.

The following code certainly matches my guess that you have not connected
the address bus up correctly. That is, you are issuing word writes because
you have declared sram_addr_data as an address to an int, yet you are
using addresses that are byte addresses (non 0 for two lsbs)

> >>
>i=268435456;
>sram_addr_data=(int *) 0x80F00000;
>*sram_addr_data = i;
>i++;
>sram_addr_data=(int *) 0x80F00001;
>*sram_addr_data = i;
>i++;
>sram_addr_data=(int *) 0x80F00002;
>*sram_addr_data = i;
>i++;
>sram_addr_data=(int *) 0x80F00003;
>*sram_addr_data = i;
>i++;

I think the thing you need to grasp is that both byte and word accesses
use the same address bits. For words, only every 4th address is valid.
i.e. addresses 0, 4, 8, 12, 16, 20, ....
This is called aligned access

You can also do byte addressing with these values, and all the ones
in between.

Most RISC CPUs run this way. Other CPUs, such as the x86 devices allow
un-aligned access, such as a word access from 3, but what actually happens
is that the CPU does 2 accesses, to 0 and 4, and then assembles the word
from byte 3 in the first word, and bytes 4, 5, and 6 in the second word.
Most RISC CPUs dont do this, including microblaze.


>This code results in the correct display in the terminal window but if I 
>try to put this in a loop to do it automatically how do I get the 
>pointer address to increment the way I need.

If the pointer is an int * then the following

	pointer++

will be incremented by 4, which will point to the next word.

If the pointer is an char * then the following

	pointer++

will be incremented by 1, which will point to the next byte.



>The SRAM device I am connecting to has a 19 bit address bus and a 32 bit 
>data bus. Am I right in thinking I should have 2^19 i.e. 524288 
>addresses each capable of holding 4 bytes therefore 2097152 bytes.

Yes

>This 
>corresponds to the documentation which says the device is 2M. Using the 
>code in my origibal post I am only getting access to a quarter of this.

Because I think you have not connected the address bus up correctly.


Philip




Philip Freidin
Fliptronics

Article: 73721
Subject: Re: VHDL inout used for non bidirectional uses
From: mike_treseler@comcast.net (Mike Treseler)
Date: 28 Sep 2004 13:22:39 -0700
Links: << >>  << T >>  << A >>
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:<10lhe4ms1oogbaa@corp.supernews.com>...

> I have an out pin (it's the
> Write*/Read SRAM line) and want to read it internally (one use would be to
> control the tristate data outputs).

If I need to read an OUT port from
the same process that drives it, 
then I have written a state machine that
lacks a process variable or architecture
signal to maintain the local state value.

For a simple entity example, a port output may be
exactly the same as the local state value.
In this case, declaring an extra variable or signal
might seem annoying.

However, for an industrial-strength entity, this
is seldom the case. Processes maintain
lots of state values that are only needed
locally. 

For example, imagine a process 
that watches an single bit IN and drives
single port bit OUT with a '1' when the input
frequency is within a certain range
or '0' otherwise.

      -- Mike Treseler

Article: 73722
Subject: Re: fast adder and equal
From: "Rune Christensen" <rune.christensen@adslhome.dk>
Date: Tue, 28 Sep 2004 22:25:44 +0200
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> skrev i en meddelelse 
news:2rti2pF1e4a0qU1@uni-berlin.de...
> Rune,
> Have you run the timing analyser to find out which path is failing? The
> '(Levels of Logic = 9)' implies that it's not the carry chain, which, for 
> a
> 28 bit counter, would be about 14 levels, 2 bits/level. I suggest you run
> the analyser and post your failing path.
> Cheers, Syms.
> "Rune Christensen" <rune.christensen@adslhome.dk> wrote in message
> news:41596bb8$0$257$edfadb0f@dread12.news.tele.dk...
>>
>>
>> I have already done that but my goal is 8 ns and a simple implementation
>> gives
>>
>> Slack:                  -1.380ns (requirement - (data path - clock path
> skew
>> + uncertainty))
>>   Source:               cnt_0 (FF)
>>   Destination:          cnt_3 (FF)
>>   Requirement:          8.000ns
>>   Data Path Delay:      9.373ns (Levels of Logic = 9)
>>   Clock Path Skew:      -0.007ns
>>   Source Clock:         clk_BUFGP rising at 0.000ns
>>   Destination Clock:    clk_BUFGP rising at 8.000ns
>>   Clock Uncertainty:    0.000ns
>>
>
>

================================================================================
Timing constraint: TS_clk = PERIOD TIMEGRP "clk"  8 nS   HIGH 50.000000 % ;

 3436 items analyzed, 17 timing errors detected. (17 setup errors, 0 hold 
errors)
 Minimum period is   8.347ns.
--------------------------------------------------------------------------------
Slack:                  -0.347ns (requirement - (data path - clock path skew 
+ uncertainty))
  Source:               cnt_0 (FF)
  Destination:          cnt_19 (FF)
  Requirement:          8.000ns
  Data Path Delay:      8.337ns (Levels of Logic = 11)
  Clock Path Skew:      -0.010ns
  Source Clock:         clk_BUFGP rising at 0.000ns
  Destination Clock:    clk_BUFGP rising at 8.000ns
  Clock Uncertainty:    0.000ns

  Data Path: cnt_0 to cnt_19
    Location             Delay type         Delay(ns)  Physical Resource
                                                       Logical Resource(s)
    -------------------------------------------------  -------------------
    CLB_R23C3.S0.YQ      Tcko                  1.292   cnt<1>
                                                       cnt_0
    CLB_R28C2.S0.F1      net (fanout=4)        1.800   cnt<0>
    CLB_R28C2.S0.COUT    Topcyf                1.486   _n0006<1>
                                                       Madd__n0006_inst_lut2_01
                                                       Madd__n0006_inst_cy_0
                                                       Madd__n0006_inst_cy_1
    CLB_R27C2.S0.CIN     net (fanout=1)        0.000   Madd__n0006_inst_cy_1
    CLB_R27C2.S0.COUT    Tbyp                  0.096   _n0006<2>
                                                       Madd__n0006_inst_cy_2
                                                       Madd__n0006_inst_cy_3
    CLB_R26C2.S0.CIN     net (fanout=1)        0.000   Madd__n0006_inst_cy_3
    CLB_R26C2.S0.COUT    Tbyp                  0.096   _n0006<4>
                                                       Madd__n0006_inst_cy_4
                                                       Madd__n0006_inst_cy_5
    CLB_R25C2.S0.CIN     net (fanout=1)        0.000   Madd__n0006_inst_cy_5
    CLB_R25C2.S0.COUT    Tbyp                  0.096   _n0006<6>
                                                       Madd__n0006_inst_cy_6
                                                       Madd__n0006_inst_cy_7
    CLB_R24C2.S0.CIN     net (fanout=1)        0.000   Madd__n0006_inst_cy_7
    CLB_R24C2.S0.COUT    Tbyp                  0.096   _n0006<8>
                                                       Madd__n0006_inst_cy_8
                                                       Madd__n0006_inst_cy_9
    CLB_R23C2.S0.CIN     net (fanout=1)        0.000   Madd__n0006_inst_cy_9
    CLB_R23C2.S0.COUT    Tbyp                  0.096   _n0006<10>
                                                       Madd__n0006_inst_cy_10
                                                       Madd__n0006_inst_cy_11
    CLB_R22C2.S0.CIN     net (fanout=1)        0.000 
Madd__n0006_inst_cy_11
    CLB_R22C2.S0.COUT    Tbyp                  0.096   _n0006<12>
                                                       Madd__n0006_inst_cy_12
                                                       Madd__n0006_inst_cy_13
    CLB_R21C2.S0.CIN     net (fanout=1)        0.000 
Madd__n0006_inst_cy_13
    CLB_R21C2.S0.COUT    Tbyp                  0.096   _n0006<14>
                                                       Madd__n0006_inst_cy_14
                                                       Madd__n0006_inst_cy_15
    CLB_R20C2.S0.CIN     net (fanout=1)        0.000 
Madd__n0006_inst_cy_15
    CLB_R20C2.S0.COUT    Tbyp                  0.096   _n0006<16>
                                                       Madd__n0006_inst_cy_16
                                                       Madd__n0006_inst_cy_17
    CLB_R19C2.S0.CIN     net (fanout=1)        0.000 
Madd__n0006_inst_cy_17
    CLB_R19C2.S0.Y       Tciny                 0.545   _n0006<18>
                                                       Madd__n0006_inst_cy_18
                                                       Madd__n0006_inst_sum_19
    CLB_R17C3.S0.F3      net (fanout=1)        1.094   _n0006<19>
    CLB_R17C3.S0.CLK     Tick                  1.352   cnt<19>
                                                       _n0002<19>1
                                                       cnt_19
    -------------------------------------------------  ---------------------------
    Total                                      8.337ns (5.443ns logic, 
2.894ns route)
                                                       (65.3% logic, 34.7% 
route)



Article: 73723
Subject: Re: Spartan-3 VCCIO ramp up time
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 28 Sep 2004 13:30:20 -0700
Links: << >>  << T >>  << A >>
Rick,

This issue is (was) new:  the ESD protection of the Vcco pins was firing 
on a high (very fast) dV/dt.  Later mask sets got fixed, but some early 
  mask sets are still in production with this restriction.

Just ramp on slower than that indicated in the data sheet, and 
everything is fine.

The protection is an active clamp (not a SCR), but it still 'latches,' 
removal of power is required to reset it.

The circuit can not be triggered in normal operation, as it is only used 
on the Vcco pins, not the IO pins themselves.

This is NOT the power on current issue that was in Virtex, Virtex E, 
Spartan 2, and Spartan 2E as you describe it.  In thoses cases, the 
current must be supplied to start up the device.  It may have acted like 
an SCR or clamp, but the mechanism was completely different.  As well, 
all of those devices were characterized, and production screens put in 
place so that we guaranteed start up if there was at least the amount of 
current specified in the data sheet present for Vccint.

Subsequent to Virtex E, we designed out the current surge issue for the 
core.  (VII, and all later parts do not have an issue with Iccint at 
startup.)

Austin

rickman wrote:
> Brian Davis wrote:
> 
>>Steven Knapp wrote:
>>
>>>The limitation is if ...
>>>
>>>* The VCCO supply ramps faster than the minimum
>>>data sheet specification (Tcco)
>>>
>>
>> One question: is this strictly a power-up issue, or can it be
>>triggered during operation?
>>
>> In particular, since the ramp spec. is worse for the leaded
>>packages, could a large transient on the VCCO supply cause
>>the same problem?
>>
>>  e.g., if you configure a PQ208 with many parallel DCI
>>terminations, at the end of configuration the VCCO supply will
>>jump instantly from quiescent to full power ( maybe ~3 amps max.
>>for a PQ208, but by that point you'd have heatsinking problems )
> 
> 
> I don't think this is a problem.  The ramp speed issue in only of
> concern at a voltage threshold around 0.8~1.0 volts.  As it was
> explained to me, when the part powers up, there are a lot of transistors
> which are turned on initially.  Once Vcc gets above about 1.0 volts,
> everything is biased and the transistors that need to be off are off. 
> But the part draws a lot of current in the meantime as the voltage
> ramps.  If the voltage ramps too fast, the PS can max out on current and
> for some reason, this will disturb the part and it will not initialize
> correctly to the point that a power down must be done to correct the
> problem.  
> 
> So the problem is that you must let the part draw as much current as it
> needs as the voltage ramps up.  The spec is to let you know how much
> current you will need for a given ramp rate.  Keep the ramp rate slower
> than the worst case spec and the part will be happy with the current
> spec'd in the data sheet.  After the voltage rises above about 1.0 volts
> this is no longer an issue regardless of how the spec is written (or
> interpreted).  
> 

Article: 73724
Subject: Re: NV on-chip memory?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Wed, 29 Sep 2004 08:45:58 +1200
Links: << >>  << T >>  << A >>
Guy wrote:

> Let me first say thank you for your responses.
> To address some of the questions / comments:
> I realize that not everyone will extract the same application or value
> from the on-chip NV memory, however, since it has the potential to
> provide or support different applications, general enough value may be
> justified for inclusion.

Since this is Horizon gazing, what about looking into FPGA+MRAM - then
you can offer SRAM to all users, and do not have to do a RAM/OTP die 
trade off - plus it is much easier to explain to users.
[FPGA designers are not always the most hardware literate :) ]

  For an example of MRAM see
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MR2A16A&nodeId=015424

> Answers / Comments for Jim and Hal: 
> a.  bad bits:  built in ECC would make bad bit transparant to the user

What about a bad row/column select line - or is enough fringe test 
memory included to test all array access lines ?

> 
> b.  speed = assume approximately 25ns access time

Any Icc projections ?
[ROM is usually quite low power]

> 
> c.  width = flexible, 16/32/64 bit

Why stop at 64 wide ?
One edge on-chip memory gives is 'free width', and that can
translate to lower power.

> d.  secure code storage would come by two assumptions:  i) on-chip
> processor preventing external need to access the memory. ii) readback
> via JTAG etc of Memory would be programmed as disabled by the user
> 
> e.  on-chip charge pumps require no special external voltage supply
> 
> f.  user application would be able to log/write data to NV memory for
> storage

Any values/estimates on write times / write energies / Block sizes ?

What about Read-While-Write - which is a common drawback in FLASH.

> g.  external applications could read NV data too, but you obviously
> loose security

But selectively, one would hope ?

> 
> h.  OTP = nonerasable
> 
> i.  no tradeoff with NV and Ram like functionality - it would be a
> standard feature, not swappable block within the silicon family

  I was meaning more Software than Hardware - the issue is development,
and early production, where users need to not have ROM. That may
mean a bigger device (with the extra SRAM), and a re-compile, or
external NV memory.

  There is also potential here for power saving, as external memory will
always be width constrained to save pins, plus have all the
BUS capacitance. Internal ROM can be wider, so use a lower clock
for the same BUS bandwidth.


> 
> j.  yes for non secure, it would enable integration into the FPGA of
> on-board NV data for some applications (mature s/w code for example). 
> Realize that also for some applications, you can create a sense of
> "virtual" unlimited multiwrite capability.  To demonstrate what I mean
> by Virtual multi-write, I'll use the following example.  Let's say
> that you know you may need to write 10,000 maximum lifetime events at
> 100 bits data each but do not need to keep history for more than 16
> events.  As a designer, you could buy a tiny block of flash or EEPROM
> of 1.6kbits and keep writing over the older events.  Or, with OTP, you
> could simply purchase enough OTP memory to store the entire lifetime
> worth of events.  Many applications that store NV data can quantify
> the lifetime of storage from a practical specification.  One example,
> Televisions need to store user configuration (like:  color, tint,
> favorite channels etc), and need to provide the user with unlimited
> adjustments of this data.  However if you make some assumption, the
> design can calculate an upper limit of needed storage.  For example,
> lets say 512bits stored, TV life is 20 years.  I would venture to
> guess that if you assumed that data storage would occur Max once a day
> for each of 20 years, you would be happy to remove the $1 EEPROM from
> the board as long as the on-chip cost of the NV block was less. 
> 20yr*512b*365days = 7Mbit total
> 
> 
> Any other creative thoughts on how this could be used would be
> appreciated.


<paste>
Nicholas Weaver wrote:
 > There is already a more secure mechanism for this: SRAM-based
 > encryption keys used to load encrypted bitfiles.  That mechanism can
 > be used to bootstrap a large non-volatile store, with a keystone of
 > the SRAM-based encyption key which is probably significantly harder to
 > reverse/crack than on-chip static bits.
 >
 > Thus the "savings" by putting it on-chip are not security, but the
 > cost savings of not needing a large external Flash PROM.

  That's true for bitstreams, but not as easy for external code.
I can see an application where the user defines a 'Rom BUS Scrambler'
that is used to load the external memory, and then reverse the scramble
on read. See the Dallas secure Microcontroller families.
Boot load code could be 'password zipped', where more time is tolerated
to unpack, and shift to the external memory.
  So you get medium levels of security, with low cost (?) silicon, and
not needing too special design flows.

-jg




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