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
2019JanFebMar2019

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 113475

Article: 113475
Subject: Re: CMI Coder/ Decoder
From: John_H <newsgroup@johnhandwork.com>
Date: Thu, 14 Dec 2006 14:40:52 GMT
Links: << >>  << T >>  << A >>
Volker wrote:
> Hello,
> did anyone know how to realize a CMI Coder/Decoder in a FPGA (preferred in 
> VHDL). Thanks for answers an tipps.
> Volker 

CMI coder is super-easy.  Understand the format and you should be able 
to code it in very few lines.

CMI decoder requires a recovered clock that is not integral to the FPGA 
except, perhaps, for some SERDES blocks.  At 140-155 Mb/s, perhaps not.

Because of the need for the recovered clock as part of the system design 
and the extremely simple coding method, I doubt you'll find pre-bundled 
code out there.

Article: 113476
Subject: Re: what are your current SoC design for ?
From: "radarman" <jshamlet@gmail.com>
Date: 14 Dec 2006 07:18:23 -0800
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> rponsard@gmail.com wrote:
> > I don't need your IP secrecies...
> >
> > This is for my students : what, in your current design, requires using
> > a fpga + softcore, in place of a COTS micro controler ?
> > less IC -> lower footprint, lower power cons., parallelism,...
>
> There are two levels of softCPU apps :
> a) The tiny ones, where the code fits inside the FPGA, in BRAM.
> b) The larger ones, that need external code memory.
>
> For a) the SoftCPU comes almost for free, and can be used to
> handle less time-critical tasks, and give a degree of
> programmability to all the other FPGA coded peripherals.
> Or they may be DSP(s), doing focused tasks.
>
> Unless you need ADCs / DACs, or similar peripherals, these
> do meet the lower footprint consideration.
>
> For b) once you have to add Code memory, you've lost the 'single chip',
> and the interface between the memory/fpga is poor for RFI & pin count.
>
>   Now it's becomes less clear-cut on which is better, and
> the choice swings somewhat, as each alternative goes thru
> generation cycles, or as code size changes.
>   If your code CAN fit into an external 32 bit uC, and meet
> speed targets, the tight local bus Code-CPU, gives the uC
> quite an edge.
>   Better 32 bit uC now have DMA SSC channels, so FPGA
> interfaces can have low pin counts, and they have quite
> impressive FLASH resource, so the SoftCPU can struggle
> against this growing option.
> Leading example: Atmels upcomming AT91SAM9XE512 Flash uC.
>
>   Once your app gets so large (MBytes), that is has outgrown uC Flash,
> and it needs SDRAM to run, then it swings more balanced.
> SDRAM uC are appearing, but not widely yet (example: AT91SAM9263),
> and both choices have PCB traces to SDRAM, so there less of a clear edge.
>
> Also, show your students this:
> http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670
>
> Details are presently sketchy, but a large dual port memory that was not
> niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs.
>
> -jg

Aye, if you require external memory, you do no longer have a single
chip solution. However, note that the Spartan 3e can boot from a NOR
Flash memory. You can configure from one end of the device, and store
your application in the other. I'm not sure if the Virtex 5's support
this feature or not, but it is quite handy on the spartan 3e sample
pack board.


Article: 113477
Subject: How to get ISE to create a _bd.bmm file for BRAM initialization
From: "Steve" <sgfallows@gmail.com>
Date: 14 Dec 2006 08:09:47 -0800
Links: << >>  << T >>  << A >>
I have an XPS/ISE project for a Xilinx Virtex II Pro. The XPS design is
called PPC_DDR and is instantiated on a top level schematic in ISE
(called JTT_DDR). I am unable to get the .bit file to be updated with
the code from the XPS application that is marked for BRAM
initialization. I cannot get ISE to create an _bd.bmm file with
placement information in it.

XPS created two files: PPC_DDR.bmm and PPC_DDR_stub.bmm, both in
JTT_DDR\PPC_DDR\implementation\. ISE created a file called
edkBmmFile.bmm in the JTT_DDR directory. edkBmmFile.bmm and
PPC_DDR_stub.bmm are identical. I have tried adding either of these
files to the ISE project and get the same result in either case. The
error message listed below is reported and a file called XpsTempBmm.bmm
is created. The XpsTempBmm.bmm file contains only the line "#include
edkBmmFile.bmm" *TWICE*. which seems to be the error and explain the
error message below.

How am I supposed to get ISE to produced the "placed" version of the
bmm file??

Error Message:
---------------------------------------
NGDBUILD done.

ERROR:Data2MEM:34 - Duplicate ADDRESS_SPACE or ADDRESS_MAP name usage
'plb_bram_if_cntlr_1_bram'.
Line #4, File "edkBmmFile.bmm".
ADDRESS_BLOCK plb_bram_if_cntlr_1_bram RAMB16 [0xffffc000:0xffffffff]
^
Line #3, File "XpsTempBmm.bmm".


FATAL:Data2MEM:43 - Release of unknown memory pointer, 0x04A85520.
Source file "../s/D2BUtil_Data2Bram_impl.c", line number 96.


Article: 113478
Subject: Re: what are your current SoC design for ?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 14 Dec 2006 08:10:53 -0800
Links: << >>  << T >>  << A >>
radarman schrieb:

> Jim Granville wrote:
> > rponsard@gmail.com wrote:
> > > I don't need your IP secrecies...
> > >
> > > This is for my students : what, in your current design, requires using
> > > a fpga + softcore, in place of a COTS micro controler ?
> > > less IC -> lower footprint, lower power cons., parallelism,...
> >
> > There are two levels of softCPU apps :
> > a) The tiny ones, where the code fits inside the FPGA, in BRAM.
> > b) The larger ones, that need external code memory.
> >
> > For a) the SoftCPU comes almost for free, and can be used to
> > handle less time-critical tasks, and give a degree of
> > programmability to all the other FPGA coded peripherals.
> > Or they may be DSP(s), doing focused tasks.
> >
> > Unless you need ADCs / DACs, or similar peripherals, these
> > do meet the lower footprint consideration.
> >
> > For b) once you have to add Code memory, you've lost the 'single chip',
> > and the interface between the memory/fpga is poor for RFI & pin count.
> >
> >   Now it's becomes less clear-cut on which is better, and
> > the choice swings somewhat, as each alternative goes thru
> > generation cycles, or as code size changes.
> >   If your code CAN fit into an external 32 bit uC, and meet
> > speed targets, the tight local bus Code-CPU, gives the uC
> > quite an edge.
> >   Better 32 bit uC now have DMA SSC channels, so FPGA
> > interfaces can have low pin counts, and they have quite
> > impressive FLASH resource, so the SoftCPU can struggle
> > against this growing option.
> > Leading example: Atmels upcomming AT91SAM9XE512 Flash uC.
> >
> >   Once your app gets so large (MBytes), that is has outgrown uC Flash,
> > and it needs SDRAM to run, then it swings more balanced.
> > SDRAM uC are appearing, but not widely yet (example: AT91SAM9263),
> > and both choices have PCB traces to SDRAM, so there less of a clear edge.
> >
> > Also, show your students this:
> > http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670
> >
> > Details are presently sketchy, but a large dual port memory that was not
> > niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs.
> >
> > -jg
>
> Aye, if you require external memory, you do no longer have a single
> chip solution. However, note that the Spartan 3e can boot from a NOR
> Flash memory. You can configure from one end of the device, and store
> your application in the other. I'm not sure if the Virtex 5's support
> this feature or not, but it is quite handy on the spartan 3e sample
> pack board.

xilinx config evolution

s3e - NOR config, multi-boot, 2 bit files, can init reconfig from
opposite direction
v5 NOR config, can select new boot address
s3a NOR config, can select new boot address, can change reboot mode, eg
start from SPI loc 0, then reboot to some location from NOR flash, then
reboot again from different address in SPI, etc.

v5,s3a also have watchdog timers

Antti


Article: 113479
Subject: Re: MicroBlaze : -mcpu=4.00.b option for mb-gcc compiler...
From: Alfmyk <Alfmyk@hotmail.com>
Date: Thu, 14 Dec 2006 08:42:37 -0800
Links: << >>  << T >>  << A >>
Hi Vasanth. Thank you for your answer.

I use it both for compiler & Linker.

Cheers,

Al.

Article: 113480
Subject: Re: FPGA : Async FIFO, Programmable full
From: "RCIngham" <robert.ingham@gmail.com>
Date: Thu, 14 Dec 2006 11:00:51 -0600
Links: << >>  << T >>  << A >>
>There is a wrong way and a right way to convert binary to Gray count
>values:
>The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
>on the binary outputs. That does you no good, since the Gray code will
>just reflect the binary transient errors.
>The right way takes the D inputs of the binary counter (, converts them
>independently to Gray and registers them in their own flip-flops. Now
>you have two parallel rgisters, both counting in step, the first in
>binary, the other in Gray, and there are no funny decoding spikes.
>BTW, only Gray counter outputs have the feature that you can compare
>two asynchronous counters for identity, without transient errors.
>If the Gray code does not come from a counter, it might change multiple
>bits per transition...

<snip />
Whether that is the right answer rather depends on WHY the OP "has" to use
Gray Code, which is still not fully established.

BTW, there is a quite interesting article on Gray Code just posted at:
http://www.pldesignline.com/showArticle.jhtml?articleID=196604078


Article: 113481
Subject: Re: How does FPGA tools infer FIFO
From: "RCIngham" <robert.ingham@gmail.com>
Date: Thu, 14 Dec 2006 11:07:13 -0600
Links: << >>  << T >>  << A >>
>KJ wrote:
>
>>>I know of no tool that infers FIFOs, async or synchronous.
>>>
>> 
>> You must be using very primitive tools.  Altera, Xilinx and Synplify
(and 
>> probably most other major players) certainly do.
>
>As far as I know they don't. That would be quite an accomplishment. I
quickly
>checked Synplify Premiere 8.6.2 manual and there was nothing about
inferring
>FIFOs. Also Mentor Precicsion 2006a Synthesis Style Guide did not tell
about
>fifo inference. And also Xilinx 8.2i xst manual did not have any text
about fifo
>inferring. Could you point me to the right page in manuals?
>
>Completely other thing is lpm_fifo and different DW_*fifo* components.
But they
>must be instantiated directly. Same applies to coregen, altera
megafunctions etc.
>
>--Kim
>
I agree with Kim. The Altera Quartus tool help shows several ways of
instantiating FIFO "macros", but apparently none of inferring one!
Inferring counters, shift registers and the like is easy, but I can't
imagine how to do so for a FIFO. I've had quite enough difficulty
inferring a ROM...



Article: 113482
Subject: Re: Can I see the detail timing parameter by Quartus II tools?
From: "RCIngham" <robert.ingham@gmail.com>
Date: Thu, 14 Dec 2006 11:10:45 -0600
Links: << >>  << T >>  << A >>
>fl wrote:
>> Hi, I still cannot get better performance, even for your code.
>
>If I assign the same device, I also get your result.
>I don't know how the author could do much better.
>That's a real old part, by the way.
>
>       -- Mike Treseler
>
>FLEX10K: EPF10K20RC240-4.     59.52 MHz ( period = 16.800 ns )
>Info: Clock "clk" has Internal fmax of 59.52 MHz between source register
>"\only:x_v[0]" and destination register "\only:sum_v[14]" (period= 16.8
ns)
>

Maybe the version of tools he was using gave a rather optimistic timing
estimate, or else he constrained the temperature to something rather
cold.


Article: 113483
Subject: Re: Maplib Error 661.
From: "beeraka@gmail.com" <beeraka@gmail.com>
Date: 14 Dec 2006 09:19:58 -0800
Links: << >>  << T >>  << A >>
I had a similar kind of error, when I was using a wrong
netlist..Basically in my source, I had a component with few ports
declared as INOUT, but the netlist just had OUT's. So MAP was failing
giving me this error. After I had the correct netlist, I never got this
error..
Hope this helps...

-- Parag

Jiten wrote:
> Hi,
> I am getting this error while implementing my design with the xilinx
> ise tool
>
> Using target part "2v6000ff1152-4".
> Mapping design into LUTs...
> ERROR:MapLib:661 - LUT4 symbol
>    "ins_part0/ins_partition_0/Partition_0_1_Multiclock_event_out127"
> (output
>    signal=fpga0_top_multiclock_event0_out_OBUF) has input signal
> "evtDetect5"
>    which will be trimmed. See the trim report for details about why the
> input
>    signal will become undriven.
>
> Error found in mapping process, exiting...
> Errors found during the mapping phase.  Please see map report file for
> more
> details.  Output files will not be written.
>
> If anybody have solved this, waiting for their positive response.
> Regards
> Jitendra


Article: 113484
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Peter Alfke" <peter@xilinx.com>
Date: 14 Dec 2006 09:50:29 -0800
Links: << >>  << T >>  << A >>
In an asynchronous FIFO, reading and writing is controlled by two
counters with independent clocks.
If you need to detect FULL or EMPTY, you compare the two counters for
identity.
If you do that with binary counters, you are vulnerable to strange
decoding glitches, while multiple binary bits change (almost, but not
quite, simultaneously). You never have that problem with Gray counters,
where only one bit changes, from one state to the next.
Peter Alfke
=============
RCIngham wrote:
> >There is a wrong way and a right way to convert binary to Gray count
> >values:
> >The wrong way hangs the (simple!) combinatorial conversion logic (XORs)
> >on the binary outputs. That does you no good, since the Gray code will
> >just reflect the binary transient errors.
> >The right way takes the D inputs of the binary counter (, converts them
> >independently to Gray and registers them in their own flip-flops. Now
> >you have two parallel rgisters, both counting in step, the first in
> >binary, the other in Gray, and there are no funny decoding spikes.
> >BTW, only Gray counter outputs have the feature that you can compare
> >two asynchronous counters for identity, without transient errors.
> >If the Gray code does not come from a counter, it might change multiple
> >bits per transition...
>
> <snip />
> Whether that is the right answer rather depends on WHY the OP "has" to use
> Gray Code, which is still not fully established.
>
> BTW, there is a quite interesting article on Gray Code just posted at:
> http://www.pldesignline.com/showArticle.jhtml?articleID=196604078


Article: 113485
Subject: Re: Virtex4 : cleaner signals?
From: John <seabass950@yahoo.com>
Date: Thu, 14 Dec 2006 10:18:57 -0800
Links: << >>  << T >>  << A >>
It is reflection and not noise, since it looks the same on every pulse.

I'm trying to use LVDCI_33 on my clock signal and LVTTL on my data lines. They're all on the same bank (7). It compiles and programs but I read there is only one IOSTANDARD allowed per bank? How come it still works?

Also, how much of a difference does it make where the source terminators are located? The interface board was designed with the source terminators closer to the destination rather than the source, unfortunately.

Thanks.

Article: 113486
Subject: Re: FPGA : Async FIFO, Programmable full
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 14 Dec 2006 10:26:03 -0800
Links: << >>  << T >>  << A >>

Kim Enkovaara wrote:
> KJ wrote:
> >
> > If someone does have an application that really requires true programmable
> > flags I'd be interested to hear about it.  The environment though is
> > - Fifo is inside a programmable part.
> > - That programmable part can be updated in system.
>
> I have many examples from telecom side. For example if you have some universal
> interface card, that has each port configurable to different protocol (for
> example STM1/4/16). That kind of big change in speed usually needs some changes
> in fifo limits to get maximum efficiency. If you have for example 8 ports that
> would need quite many different FPGA images to cover static settings. Also
> partial reconfiguration in my opinion is little too dififficult way to handle
> this problem.
>
> Of course you can code the static values for each protocol and use mux to select
> one of them to the fifo comparison logic. But it's easier just to add
> one register and let the software to handle the values. Also usually maximum
> efficiency needs some lab testing to find the optimal fifo values. And waiting
> hours for new fpga after each change in the limits is not fun.
>
> I have used programmable flags so many times in lab while debugging different
> problems in the design, and while trying to understand the dynamics how different
> limits affect interconnected fifo fystems between chips etc.
>

Having a single fifo with (in your case) 8 different flags come out at
those 8 different fill levels would accomplish the same thing.  The
only thing that needing muxing would be the 8 different flags not 8
entire fifos.  Software would write to a register which would select
one of the 8 pre-defined constants.

At some point though the logic required to generate an arbitrary number
of flags that are comparisons of the fill level to a set of fixed
constants becomes greater than the cost to compare the fill level to a
programmable register.  At what point that you cross that threshold
depends on the number of bits in the counter, but in the cases where
I've run across it was cheaper (in logic) and faster in performance to
do the multiple comparisons and select but that was with 4 sets of fill
levels....8 choices might just push you over.

I agree that lab testing to empirically find those optimal values can
be a pain when it means an FPGA rebuild but once beyond that and the
optimal values determined they usually tend to stay set in concrete.
Hard coding them in at that point would tend to give you less logic and
better performance (again, how much depends on the counter size).

Good example.

KJ


Article: 113487
Subject: Re: FPGA : Async FIFO, Programmable full
From: "Tommy Thorn" <tommy.thorn@gmail.com>
Date: 14 Dec 2006 10:43:33 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> In an asynchronous FIFO, reading and writing is controlled by two
> counters with independent clocks.
> If you need to detect FULL or EMPTY, you compare the two counters for
> identity.
> If you do that with binary counters, you are vulnerable to strange
> decoding glitches, while multiple binary bits change (almost, but not
> quite, simultaneously). You never have that problem with Gray counters,
> where only one bit changes, from one state to the next.

How about a different way? Couldn't one simply maintain two views (one
for each clock) of the state of the FIFO, always a conservative
approximation to the "true" state, and use standard handshake
techniques to communicate to the writer "since our last handshake, I've
dequeued X words", and visa versa.

The advantage of this (besides simplicity) is that one can pipeline the
handshake arbitrarily much, only at the expense of added latency
between full->non-full and empty->non-empty transitions.

Isn't this a standard technique?

Tommy


Article: 113488
Subject: Re: How does FPGA tools infer FIFO
From: "Andy" <jonesandy@comcast.net>
Date: 14 Dec 2006 10:44:07 -0800
Links: << >>  << T >>  << A >>
Show me...  What tool (and what code!) infers a FIFO from RTL
functional code?

Today's latest tools can infer _memories_ from rtl functional
descriptions, even dual port ones, but not FIFOs.

There aren't any yet that can even infer the port size changing
hardware built into some block rams. You can roll your own, but it will
use luts, etc. to build the extra hardware, not  use the built-in
features of the memory primitive.

Andy

KJ wrote:
> "John_H" <newsgroup@johnhandwork.com> wrote in message
> news:tz5gh.7746$Li6.5593@trndny03...
> > ashish.dobhal@gmail.com wrote:
> >> In the presence of numerous styles for designing asynchronous FIFOs,
> >> how does FPGA synthesis tools infer the FIFO specified in RTL?
> >>
> >> Thanks in advance.
> >>
> >> Ashish
> >
> > I know of no tool that infers FIFOs, async or synchronous.
> >
> You must be using very primitive tools.  Altera, Xilinx and Synplify (and
> probably most other major players) certainly do.
>
> As to the original question there probably aren't really that many 'styles'
> as you may think.  One time through whatever part of the tool chain it is
> that takes the raw source code and converts it to something equivalent but
> easier for the downstream tools to chew on and those supposedly numerous
> styles likely all pop out looking the same.  Remember, no matter how you
> code it, the functionality of the fifo isn't changing.
>
> After all, there are many ways to code just a flip flop and the tools can
> recognize all of those as well so you could rightly ask the same question
> about how the tools detect a flip flop.
> 
> KJ


Article: 113489
Subject: Re: How does FPGA tools infer FIFO
From: Mike Treseler <mike_treseler@comcast.net>
Date: Thu, 14 Dec 2006 10:52:33 -0800
Links: << >>  << T >>  << A >>
RCIngham wrote:

> I agree with Kim. The Altera Quartus tool help shows several ways of
> instantiating FIFO "macros", but apparently none of inferring one!
> Inferring counters, shift registers and the like is easy, but I can't
> imagine how to do so for a FIFO. I've had quite enough difficulty
> inferring a ROM...

I can *design* a fifo by inferring dpram
and counters. The only reason I can't
infer the vendor fifos exactly is
that the vendors don't want to give
away the source code for such a template.

             -- Mike Treseler

Article: 113490
Subject: Re: How to get ISE to create a _bd.bmm file for BRAM initialization
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 14 Dec 2006 13:52:50 -0500
Links: << >>  << T >>  << A >>
> How am I supposed to get ISE to produced the "placed" version of the
> bmm file??

The "placed" version is actually produced by bitgen, i.e. you need to run 
the Generate Programming File process if you use GUI...

/Mikhail 



Article: 113491
Subject: Re: electrical interface problem LVPECL - LVDS multi-inputs
From: "Andy" <jonesandy@comcast.net>
Date: 14 Dec 2006 10:54:30 -0800
Links: << >>  << T >>  << A >>
Those clock inputs cannot be configured as LVPECL? I know general
purpose differential inputs can be LVPECL. You have to terminate on
board though.

Are there other things on board clocked off the same clock? If not
(i.e. nothing external is synchronous to that clock somewhere, then
what does it matter which side you get into the FPGA on; just pick one
and build the board that way. I can't imagine the FPGA clock design
would be nearly as complex (or risky) as what you want to do on the
board.

Andy

Kurt Kaiser wrote:
> "Andy" <jonesandy@comcast.net> schrieb im Newsbeitrag
> news:1166052157.531419.185640@l12g2000cwl.googlegroups.com...
> > Why do you need to connect the same clock to more than one clock input
> > on your FPGA? What kind of FPGA are you using?
> >
> > If I had to buffer and translate, I would rather translate, then
> > buffer. Unless you are very careful with your resistors and
> > interconnect, a resistor translator may not work too well.
> >
> > Andy
>
> Thanks so far for your answer. I'm using Virtex-4 FX60. Depending on the
> implemented designs I will use either the clock input on one side or the
> other, not both the at the same time of course. So I'm hoping for more
> flexibility and freedom of clock routing if I have two clocks available and
> stick to the one that fits better from design to design. The FPGA's input is
> LVDS.


Article: 113492
Subject: Re: NOR Flash Controller
From: PeteS <peter.smith8380@ntlworld.com>
Date: Thu, 14 Dec 2006 20:03:31 GMT
Links: << >>  << T >>  << A >>
lbo_user wrote:
> Thanks Pete,
> 
> I'm happy with the functionality of the flash, I'm more concerned with
> the amount of effort needed to write my own controller.  The majority
> of the work looks to be in the program/erase polling state machines.
> I'm just really short on time and have been looking for faster
> alternatives to writing my own controller.  It's looking more and more
> like that's the way I'll have to go though.
> 
> Ta.
> 

I am sure there are cores out there; this is not a new area. Have you 
asked the FPGA vendors or checked the third party links?

Cheers

PeteS

Article: 113493
Subject: Re: abel to vhdl converter
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Fri, 15 Dec 2006 10:20:55 +1300
Links: << >>  << T >>  << A >>
lingamaneni.naveen@gmail.com wrote:

> Hello Guys,
> First of all thanks for all of your valuble suggestions.I was able to
> get the source code (ABEL) for all the PAL's now.Since most of the
> PAL's were absolute now and for ROHS compliance we are redesigning the
> board and now we want to replace bulky PAL's around 70 

Wow, that's some sea-of-pals!
What parts are they ?

> and eight XC3130 series(VHDL) into state of the art FPGA devices.

Does this need to be 'instant-on' ? - or 5V complaint ?

> Coming to my first point
> 1. Can i have a VHDL main module and integrate all the individual .ABL
> files as it is and achieve the same functionality of all the PAL's
> within FPGA.
> (With out converting ABEL to VHDL)

See Gabor's post. This sounds worth trying, perhaps on a couple
of Xilinx tool flows (and I think Lattice also have Abel in their
flows )

> 
> 2. Here the board performance (timing of PAL) has to remain the same
> with high speed FPGA also.Never worked on timing issues till now but
> heard registering and using flip flop can solve problem any better
> ideas?
> (First i am working out on how to get the timing of a PAL from the old
> board before knowing how to achieve the same timing with in a high
> speed FPGA )
> 
> Sorry for my list of questions and Thanks for being supportive.

This could be interesting...
  Trying to actually match timing is not going to be easy.
If the PLD code is all Clock-based, then you only need to be
'the same, or faster' on the FPGA.
- but the PLD code may not be quite that clean....

  I'd suggest a scan of the Abel sources, and also compile the sources 
you have (minimal changes, non-merged), to a legal target (XC2C32A?),
and read the warnings and fitter report files.
  The try merge of a couple of sources, into one Abel source file,
if you use PIN for the external signals, and nodes for the ones that
are only pal-pal, then the tools can optimise if they need to, or
use keep if you want to avoid that.

-jg






Article: 113494
Subject: Port OS: Error when generate the Libraryies and BSPs
From: "Thang Nguyen" <airthang@yahoo.com>
Date: Thu, 14 Dec 2006 14:14:02 -0800
Links: << >>  << T >>  << A >>
Hi, I start to work on FPGA Embedded system. I am trying to port the MonstaVista Linux on the system. First I built the system with EDK, the option for my system is: XUPV2P: powerPC 405 300MHz Bus 100MHz RS232_Uart_1 OPB UART 16550 (interrupt) Ethernet_MAC OPB ETHERNET (interrupt) SysACE_Compact Flash (interrupt) DDR_512MB

I continue to work on software platform which is: Linux_mv131 version 1.01.b MEM_SIZE 0x10000000 PLB_CLOCK_FREQ_HZ 100000000 (100 MHz) Connected_periphs RS232_Uart_1, Ethernet_MAC, SysACE_CompactFlash, opb_intc_0

After generate the bitstream, then Generate Libraries and BSPs, I meet this error:

TARGET_DIR : D:\My_Researches\Workspace\Report2\os\ ERROR:MDT - ERROR FROM TCL:- linux_mvl31 () - /usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `"' /usr/bin/bash: -c: line 2: syntax error: unexpected end of file while executing "exec bash -c "cp -Rfp $cur_dir/linux/* $value"" (procedure "::sw_linux_mvl31_v1_01_b::post_generate" line 166) invoked from within "::sw_linux_mvl31_v1_01_b::post_generate 43482512"

ERROR:MDT - Error while running "post_generate" for processor ppc405_0...

make: *** [ppc405_0/lib/libxil.a] Error 2

If you meet this before, PLease give me some recommendation. I highly appreciate your help. Thang Nguyen

Article: 113495
Subject: Re: Opencores DDR SDRAM controller
From: "cippalippa" <menchinidaniele@tiscali.it>
Date: 14 Dec 2006 14:26:22 -0800
Links: << >>  << T >>  << A >>
Frank Buss ha scritto:


> 50 MHz is not good, because it violates timing of the DDR RAM. Use this
> code for generating 266 MHz:
>
>   -- Spartan 3E stepping 0, speed grade -4 devices:
>   -- CLKFX frequency in "high" mode: min: 220 MHz, max: 307 MHz
>   clock266: dcm_sp
>     generic map(
>       clkfx_multiply => 16,
>       clkfx_divide => 3,
>       clkin_period => 4.0,
>       dfs_frequency_mode => "HIGH")
>     port map(
>       clkfx => clk_266mhz,
>       clkin => clk_50mhz);
>
> As far as I understand, you can't divide to 133 MHz, because the datasheet
> specifies different ranges for high and low mode for the speed grade -4
> devices, so I've used this additional code for dividing 266 MHz by two:
>
>   -- divide 266 MHz to system clock
>   clock_divide: process(clk_266mhz)
>   begin
>     if rising_edge(clk_266mhz) then
>       clk_133mhz <= not clk_133mhz;
>     end if;
>   end process;
>
> The signals:
>
>   signal clk_266mhz: std_logic := '0';
>   signal clk_133mhz: std_logic := '0';
>
> Imports:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.NUMERIC_STD.ALL;
> use IEEE.MATH_REAL.ALL;
>
> Library UNISIM;
> use UNISIM.vcomponents.all;
>
> At least it works for my TCP/IP receiver/sender core, let me know, if it
> works with your DDR implementation and maybe upload the project somewhere
> or submit your modifications to the Open Cores project.
>
> --
> Frank Buss, fb@frank-buss.de
> http://www.frank-buss.de, http://www.it4-systems.de

Hello,

now the controller work at 133MHz; I use directly the DCM like this:

clk_in_ibufg :  IBUFG port map (I=>sys_clk_pin, O=>CLKIN_IBUFG);

DCM_SP_INST : DCM_SP	generic map(
        CLK_FEEDBACK => "NONE",
        CLKDV_DIVIDE => 2.0,
        CLKFX_DIVIDE => 3,
	CLKFX_MULTIPLY => 8,
	CLKIN_DIVIDE_BY_2 => FALSE,
	CLKIN_PERIOD => 20.0,
	CLKOUT_PHASE_SHIFT => "NONE",
	DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",
	DFS_FREQUENCY_MODE => "LOW",
	DLL_FREQUENCY_MODE => "LOW",
	DUTY_CYCLE_CORRECTION => TRUE,
	FACTORY_JF => x"C080",
	PHASE_SHIFT => 0,
	STARTUP_WAIT => FALSE)
port map (
        CLKFB=>'0',
	CLKIN=>CLKIN_IBUFG,
	DSSEN=>'0',
	PSCLK=>'0',
	PSEN=>'0',
	PSINCDEC=>'0',
	RST=>sys_rst_pin,
	CLKFX=>CLKFX_BUF,
	LOCKED=>rst_n,
	PSDONE=>open,
	STATUS=>open);

clkfx_bufg : BUFG port map (I=>CLKFX_BUF, O=>clk100mhz);

where sys_clk_pin is the S3E board clock (at 50MHz).
Why do you think that is better to use 266Mhz and after divide by 2 the
clock? (is the jitter better?)
May I also know if sameone say me how can I modify the controller to
use all the DDR memory (the opencore's DDR is for 256 Mbit but I have a
512 Mbit).
Thanks for all.

Daniele


Article: 113496
Subject: Virtex-V MGT SONET alignment
From: Kolja Sulimma <news@sulimma.de>
Date: Thu, 14 Dec 2006 23:44:29 +0100
Links: << >>  << T >>  << A >>
Hi!

Does anybody here have experience with Virtex-4 MGTs in SONET alignment
configuration?

We turn of ENPCOMMAALIGN and ENMCOMMAALIGN immediately after we see
COMMDA_DETECT and still the byte aligner shifts bits around the next
time it sees an A1 or A2 pattern.(This happens a couple of clock cycles
after the sync pattern of 12 times A1 folloed by 12 times A2 was received.

Kolja Sulimma
cronologic ohg

Article: 113497
Subject: Virtex-II Pro: Reading/Writing data with Compact Flash
From: "abright52" <abright52@gmail.com>
Date: 14 Dec 2006 15:34:26 -0800
Links: << >>  << T >>  << A >>
Hello,
  We are using the Xilinx Virtex-II Pro Developement System XUP-V2P.
Our objective is to read a binary file that contains 0101 into the
board from the compact flash card, then modify the file and write it
back to the board.  Right now we would just like to invert the numbers,
to make things simple.

  Our main problem is when we connect the CF Card to the Board the
SYSTEM ACE ERROR light illuminates.  We have checked to make sure that
it is formatted correcly using mkdosfs, as recommended by Xilinx.  The
only thing loaded on the card is our .bin file.

  Does anyone know what else could cause this?

Thank you.


Article: 113498
Subject: Re: Opencores DDR SDRAM controller
From: Frank Buss <fb@frank-buss.de>
Date: Fri, 15 Dec 2006 00:56:17 +0100
Links: << >>  << T >>  << A >>
cippalippa wrote:

> where sys_clk_pin is the S3E board clock (at 50MHz).
> Why do you think that is better to use 266Mhz and after divide by 2 the
> clock? (is the jitter better?)

See the datasheet ds312.pdf page 145: For stepping 0, speed grade -4
devices, like on my S3E board, there are 2 DFS_FREQUENCY_MODE modes: low
and high. For low CLKOUT_FREQ_FX has to be between 5 and 90 MHz and for
high it must be between 220 and 307 MHz. At least this is how I interpret
it.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 113499
Subject: Adding Jitter
From: "sonetguest" <sanjay112@gmail.com>
Date: 14 Dec 2006 16:08:38 -0800
Links: << >>  << T >>  << A >>
Why do we do a quadratic add of jitter when calculating total jitter.
For example, with an input jitter of +/- 100 pS, and a DCM jitter of
+/- 100pS, will there not be an instant (with very low probability)
that when the input hits the -100pS, the DCM follows it with another -
100pS, leading to a total time period narrowing of 200pS?




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
2019JanFebMar2019

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