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 100950

Article: 100950
Subject: Re: fpga space estimate
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 21 Apr 2006 09:01:25 -0700
Links: << >>  << T >>  << A >>
Roger,

Depending on speed, using an FPGA can be exactly like using a DSP.

The use of the BRAM basically means you are building a custom DSP 
machine, which will 'execute' a fixed program (based on a FSM), 
manipulating the BRAM contents much like a DSP would bring operands in 
and out of the ALU, to and from memory.

Personally, if something this slow would work, to make your life easier, 
you might consider Microblaze as the processor, and execute both program 
and data from BRAMs.  That way the program (which may already be in c 
code) could remain in c code.

Or, alternatively, use a "real" DSP processor, as (let's be honest) the 
FPGA may be extreme overkill for what you may be doing.

If the speed there is just not fast enough, there may be hardened FFT 
filter structures that are serial, rather than parallel, which still may 
be fast enough (faster than a DSP), and yet use fewer resources (than a 
full parallel one).  The SRL16s are particularly good at this, as you 
have up to 16 FFs for the SLICEs with SRLs/LUTRAM.

Remember that a parallel multiply may not be needed, and a serial 
multiplier may be a lot less hungry (for resources, overall).

Many extreme audio applications (see NAB conference) use serial 
processing of many audio streams at once on a signle FPGA for a superb 
cost/performance point.

http://biz.yahoo.com/prnews/060419/sfw113.html?.v=30

Finally, if the problem can be partitioned in time into more than one 
piece, I have seen people calculate part 1, store results in an external 
SRAM, reconfigure, and then read in last part and calculate part 2, 
store results in external SRAM, etc...

Austin

Article: 100951
Subject: More Xilinx S/W problems... ISE won't start
From: "johnp" <johnp3+nospam@probo.com>
Date: 21 Apr 2006 09:03:08 -0700
Links: << >>  << T >>  << A >>
I installed SP3 for ISE 8.1 (webpack) yesterday and used it for a bit.

I then ran a multi-pass P&R, then, when it was done, killed the program
and
shut down my computer.  When I started up today, ISE won't run.  I get
the start-up windows, but it appears to hang with the process _pn.exe
running.  Windows task manager reports that "Xilinx - ISE" is "Not
Responding".

Anyone else run into this?

Is it just me, or does the Xilinx s/w appear to be getting worse?  The
user
interface on 8.1 seems very slow when compared to 6.1.  XST takes
a lot longer than it used to.  If it weren't for the updated speed
files,
I'd go back to 6.1 in a heart beat.

John Providenza


Article: 100952
Subject: Re: CAM, TCAM in Stratix
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 21 Apr 2006 09:03:25 -0700
Links: << >>  << T >>  << A >>
Freechip,

http://www.xilinx.com/products/design_resources/mem_corner/grouping/cam.htm

I am not suggesting you switch to Xilinx, but we do have answers.

Austin

freechip wrote:

> Hi,
> I am working on a 10 Gb Ethernet project (deep packet inspection) and need
> to implement CAM in my FPGA. I am using a Stratix GX and I don't think I
> can use CAM (internal or external) in the stratix GX Dev Board.
> 
> Let me know your thoughts about that.
> 
> Thanks a lot.

Article: 100953
Subject: Re: CAM, TCAM in Stratix
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Apr 2006 16:09:26 GMT
Links: << >>  << T >>  << A >>
"freechip" <freechip@hotmail.fr> wrote in message 
news:VqSdnSn0Kpv2YtXZRVn_vA@giganews.com...
>
> Hi,
> I am working on a 10 Gb Ethernet project (deep packet inspection) and need
> to implement CAM in my FPGA. I am using a Stratix GX and I don't think I
> can use CAM (internal or external) in the stratix GX Dev Board.
>
> Let me know your thoughts about that.
>
> Thanks a lot.

How big a (Ternary?)CAM do you need? 



Article: 100954
Subject: Re: More Xilinx S/W problems... ISE won't start
From: "johnp" <johnp3+nospam@probo.com>
Date: 21 Apr 2006 09:16:19 -0700
Links: << >>  << T >>  << A >>
I found a work-around - I delete the bulk of the files from my
working directory including the .ise file and now ISE starts
up.  I copied in an older 6.1 .npl file and told ISE to convert it
to the newer 8.1 project file.

John Providenza


Article: 100955
Subject: Re: fpga space estimate
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Apr 2006 16:19:40 GMT
Links: << >>  << T >>  << A >>
"Roger Bourne" <rover8898@hotmail.com> wrote in message 
news:1145634375.780378.146980@t31g2000cwb.googlegroups.com...
<snip>
> BlockRAM. Great idea! I checked the timing specs of the blockram
> module, and it seems pretty fast.1clock cycle to write and 1 clock
> cycle for read. max freq of ~160MHz. No need for a complex multiplexing
> network. In fact, there is no need for delay elements
> (FFs)alltogether!.
>
> However, I never used RAM on an FPGA (that is the reason I did not
> initially lean towards that solution). Is there some obvious, flagrant
> , blatant drawback when using RAM , instead of FFs ? Especially since
> there is 36 times more RAM bits than available FFs (288K vs 8K). And in
> RAM, ALL the bits can be used!
>
> According to the timing waveform in the specs, it only requires 1 cycle
> for read and 1 cycle for write --so I do not think loss of cycles
> between data transters will be an issue, especially if the data rate is
> ~150 times slower than the fastest clock available. The module that
> performs the multiplication can thus be time-multiplexed.
>
> It is sounds like it is working on a DSP, rather than a FPGA, if one
> foregoes the use of FFs...:-)
>
> -Roger

If you want a dedicated port to a controller to allow on-the-fly update of 
coefficient values, a dual-port RAM would implement the controller on one 
port and the data I/O on the other.  If you have a fixed configuration, you 
can dedicate one port for read, one for write, and your data can flow at the 
full 320 MHz BlockRAM rate.  Dual-ports are great.

Initializing BlockRAM contents always seems a little tough with the 
synthesis and simulation tools never quite making it practical to get 
everything flowing just right.  If you look into the help or app notes from 
the various tools, you could have pre-initialized BlockRAMs for fixed 
coefficients to make life simpler.

For your application, this really *is* best implemented in a DSP mindset; 
you can keep your resources low (1 MAC) and maintain the values in a 
register file with limited I/O in your algorithm.  Since you have 100x+ the 
sample rate to do your processing, the system flows beautifully.  The only 
question for me would be how complex the state machine or microcode would 
need to be to have the system work beautifully without adding a generic 
processor like the MicroBlaze or similar.  This is where prototyping with 
pseudo-code and an Excel spreadsheet get me to my results with a simple 
implementation.

For me, these kinds of tasks are great fun. 



Article: 100956
Subject: Re: fpga space estimate
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 21 Apr 2006 09:51:06 -0700
Links: << >>  << T >>  << A >>

John_H wrote:
> "Roger Bourne" <rover8898@hotmail.com> wrote in message
> news:1145634375.780378.146980@t31g2000cwb.googlegroups.com...
> <snip>
> > BlockRAM. Great idea! I checked the timing specs of the blockram
> > module, and it seems pretty fast.1clock cycle to write and 1 clock
> > cycle for read. max freq of ~160MHz. No need for a complex multiplexing
> > network. In fact, there is no need for delay elements
> > (FFs)alltogether!.
> >
> > However, I never used RAM on an FPGA (that is the reason I did not
> > initially lean towards that solution). Is there some obvious, flagrant
> > , blatant drawback when using RAM , instead of FFs ? Especially since
> > there is 36 times more RAM bits than available FFs (288K vs 8K). And in
> > RAM, ALL the bits can be used!
> >
> > According to the timing waveform in the specs, it only requires 1 cycle
> > for read and 1 cycle for write --so I do not think loss of cycles
> > between data transters will be an issue, especially if the data rate is
> > ~150 times slower than the fastest clock available. The module that
> > performs the multiplication can thus be time-multiplexed.
> >
> > It is sounds like it is working on a DSP, rather than a FPGA, if one
> > foregoes the use of FFs...:-)
> >
> > -Roger
>
> If you want a dedicated port to a controller to allow on-the-fly update of
> coefficient values, a dual-port RAM would implement the controller on one
> port and the data I/O on the other.  If you have a fixed configuration, you
> can dedicate one port for read, one for write, and your data can flow at the
> full 320 MHz BlockRAM rate.  Dual-ports are great.
>
> Initializing BlockRAM contents always seems a little tough with the
> synthesis and simulation tools never quite making it practical to get
> everything flowing just right.  If you look into the help or app notes from
> the various tools, you could have pre-initialized BlockRAMs for fixed
> coefficients to make life simpler.
>
> For your application, this really *is* best implemented in a DSP mindset;
> you can keep your resources low (1 MAC) and maintain the values in a
> register file with limited I/O in your algorithm.  Since you have 100x+ the
> sample rate to do your processing, the system flows beautifully.  The only
> question for me would be how complex the state machine or microcode would
> need to be to have the system work beautifully without adding a generic
> processor like the MicroBlaze or similar.  This is where prototyping with
> pseudo-code and an Excel spreadsheet get me to my results with a simple
> implementation.
>
> For me, these kinds of tasks are great fun.



> This is where prototyping with
> pseudo-code and an Excel spreadsheet get me to my results with a simple
> implementation.

pseudo-code ??? 
What exactly do you mean by peudo-code?

-Roger


Article: 100957
Subject: Re: Initializing array of BlockRAM instances in verilog
From: "Allan" <allanca@gmail.com>
Date: 21 Apr 2006 10:00:09 -0700
Links: << >>  << T >>  << A >>
Thanks. Good idea, but it doesn't change anything. I forgot to mention
above that it seems that this is more attached to the #() parameter
initialization part because using these INITs with a non-array
instantiation causes the same problem:

RAMB16_S36_S36 #(.WRITE_MODE_A("READ_FIRST"), .INIT_A(36'h012345678))
BRAM (.ADDRA(ADDRA), ...


-Allan


Article: 100958
Subject: Why Edge is required to read from Block RAM of V4
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 21 Apr 2006 10:01:16 -0700
Links: << >>  << T >>  << A >>
Hello all,
    Why xilinx is using edges to read from block RAM. That wont be a
problem in most cases. But i am trying to implement the 16 port
read/wrte RAM by a method suggested in an earlier post. The RAM is
constructed with lot of individual RAM units. And in this there is a
need to write to a RAM with input data XOred with data from other RAMs.
But if we need an edge to read from the memory content this is not
possible. Other method is to use +ve edge for reading and negedge for
writng. But this is also not possible because there is one more read is
required in the same cycle. Any comments.
regards
Sumesh V S


Article: 100959
Subject: Re: Why Edge is required to read from Block RAM of V4
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Apr 2006 17:59:25 GMT
Links: << >>  << T >>  << A >>
A 16 *port* RdWr memory requires the equivalent of about 256 BlockRAMs.  You 
sure about this?
Do you mean 16 entry?

"vssumesh" <vssumesh_asic@yahoo.com> wrote in message 
news:1145638876.886174.164400@i39g2000cwa.googlegroups.com...
> Hello all,
>    Why xilinx is using edges to read from block RAM. That wont be a
> problem in most cases. But i am trying to implement the 16 port
> read/wrte RAM by a method suggested in an earlier post. The RAM is
> constructed with lot of individual RAM units. And in this there is a
> need to write to a RAM with input data XOred with data from other RAMs.
> But if we need an edge to read from the memory content this is not
> possible. Other method is to use +ve edge for reading and negedge for
> writng. But this is also not possible because there is one more read is
> required in the same cycle. Any comments.
> regards
> Sumesh V S
> 



Article: 100960
Subject: Re: Xilinx DCI resistor placement guidelines
From: mr_dsp@myrealbox.com
Date: Fri, 21 Apr 2006 11:00:08 -0700
Links: << >>  << T >>  << A >>
On 17 Apr 2006 22:03:58 -0700, "Andrew FPGA"
<andrew.newsgroup@gmail.com> wrote:

>Hi,
>I have been unable to find any info/guidelines for PCB placement of the
>DCI reference resistors. I.e. the resistors that attach to VRN and VRP.
> My instinct says decoupling capacitors highest priority (closest to
>FPGA package), DCI resistors next priority, and everything else lowest
>priority.
>
>How senstive to noise are the VRP/VRN inputs?
>
>FPGA is XC3S200-4FT256 and I'm using 49R9 DCI reference resistors.
>
>Regards
>Andrew

Great resource for decoupling cap placement and component priorities:

http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf

According to this power distribution app note, page 12, placement of
termination resistors  takes precedence over decoupling caps.  The DCI
reference resistors function like termination resistors.

I have designed four different working boards using Virtex II Pro
and/or Virtex 4 chips, and always put the DCI resistors closest to the
FPGA on the ball layer. I can usually squeeze in a bunch of 0.01uF
0402 caps in the first ring around the FPGA perimeter on the ball
layer.  More 0.01uF caps on the bottom layer.  Next ring has  0.1uF
caps on ball and bottom layers, etc.

I always use side vias to power and gnd planes on my decoupling caps
(Page 6) to minimize inductance. Never have room for two vias per cap
lead (Fig 6D).

Do a search on "DCI" in the Xilinx Answers database for more info.

Hope this is helpful.

Article: 100961
Subject: Re: fpga space estimate
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 21 Apr 2006 18:15:52 GMT
Links: << >>  << T >>  << A >>
"Roger Bourne" <rover8898@hotmail.com> wrote in message 
news:1145638266.357322.108180@i39g2000cwa.googlegroups.com...
>
> John_H wrote:
>> This is where prototyping with
>> pseudo-code and an Excel spreadsheet get me to my results with a simple
>> implementation.
>
> pseudo-code ???
> What exactly do you mean by peudo-code?
>
> -Roger

Just writing down what ssteps you'd take to implement the code in your data 
path.  It's helpful to "see" the data pipeline by looking at the steps and 
the loops to manipulate the data. 



Article: 100962
Subject: Re: XST duplicate register option does not work
From: "Gabor" <gabor@alacron.com>
Date: 21 Apr 2006 11:37:47 -0700
Links: << >>  << T >>  << A >>

Brannon wrote:
> I have an application that has 300 pins on a tri-stated bus. They have
> a tight offset constraint for the output time. Driving the T on the
> OBUFT for all those off the same line fails time spec because the
> fanout (of 300) stretches the time a little too long. In Synplicity,
> you turn on the duplicate register option, and it will duplicate the
> last register on the T line 300 times so that the timespec will pass.
> XST is clueless. It seems to not even care that it is failing timespec;
> it does no register duplication to fix failed OFFSET constraints. I had
> to duplicate the register myself by declaring a bunch of them. Anyone
> else seen the same issue?

I've done the same thing myself.  I noticed that XST will duplicate a
register
to go into an IOB if it is also used internally (one register for
feedback
and another going out), but I haven't seen it duplicate registers to
reduce fanout.  If you also have a fast clock, be aware that the signal
driving your 300 OBUFT D-FF's may have a tough time meeting the
period spec...

Good luck,
Gabor


Article: 100963
Subject: Re: Initializing array of BlockRAM instances in verilog
From: "Gabor" <gabor@alacron.com>
Date: 21 Apr 2006 11:47:17 -0700
Links: << >>  << T >>  << A >>

Allan wrote:
> Thanks. Good idea, but it doesn't change anything. I forgot to mention
> above that it seems that this is more attached to the #() parameter
> initialization part because using these INITs with a non-array
> instantiation causes the same problem:
>
> RAMB16_S36_S36 #(.WRITE_MODE_A("READ_FIRST"), .INIT_A(36'h012345678))
> BRAM (.ADDRA(ADDRA), ...
>
>
> -Allan

I know this sounds dumb, but could the order of parameters be the
problem?
In the simprims and unisim libraries I noticed that INIT_A is the first
parameter
in the list. Maybe...

RAMB16_S36_S36 #(.INIT_A(36'h012345678), .WRITE_MODE_A("READ_FIRST"))
BRAM (.ADDRA(ADDRA), ...


Article: 100964
Subject: Re: Xilinx DCI resistor placement guidelines
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 21 Apr 2006 12:05:01 -0700
Links: << >>  << T >>  << A >>
All,

Placement close to the chip is preferred, but since the ratio is 1:1, 1: 
1:1/2 or 1:2 (ie a 50 ohm resistor can be used for a 25 ohm drive 
strength, or a split 100 ohm termination for 50 ohms), the impedance is 
low enough that coupling to the pin and causing it to not terminate 
correctly is unlikely.

There are DCI resistors for other companies chips which use a 10:1 
ratio, so a 500 ohm resistor is used for a 50 ohm termination.  One must 
be much more concerned with those resistors (as they are 10 times easier 
to couple to).

I would not put the resistor ahead of where a bypass capacitor would go, 
(bypassing is more important IMHO), but I would place it within 2 to 3" 
of the device, and I would not place strongly switching traces 
immediately adjacent to that 2 to 3" trace!  I typically use a 3X 
spacing rule for reference resistors (and reference voltage pins), so 
that the trace to these pins has 3 times the normal spacing between 
traces to them.  That takes the cross coupling to 1/9 a normally spaced 
pair of traces, which should be sufficient (but you should check anyway!).

Austin

mr_dsp@myrealbox.com wrote:

> On 17 Apr 2006 22:03:58 -0700, "Andrew FPGA"
> <andrew.newsgroup@gmail.com> wrote:
> 
> 
>>Hi,
>>I have been unable to find any info/guidelines for PCB placement of the
>>DCI reference resistors. I.e. the resistors that attach to VRN and VRP.
>>My instinct says decoupling capacitors highest priority (closest to
>>FPGA package), DCI resistors next priority, and everything else lowest
>>priority.
>>
>>How senstive to noise are the VRP/VRN inputs?
>>
>>FPGA is XC3S200-4FT256 and I'm using 49R9 DCI reference resistors.
>>
>>Regards
>>Andrew
> 
> 
> Great resource for decoupling cap placement and component priorities:
> 
> http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf
> 
> According to this power distribution app note, page 12, placement of
> termination resistors  takes precedence over decoupling caps.  The DCI
> reference resistors function like termination resistors.
> 
> I have designed four different working boards using Virtex II Pro
> and/or Virtex 4 chips, and always put the DCI resistors closest to the
> FPGA on the ball layer. I can usually squeeze in a bunch of 0.01uF
> 0402 caps in the first ring around the FPGA perimeter on the ball
> layer.  More 0.01uF caps on the bottom layer.  Next ring has  0.1uF
> caps on ball and bottom layers, etc.
> 
> I always use side vias to power and gnd planes on my decoupling caps
> (Page 6) to minimize inductance. Never have room for two vias per cap
> lead (Fig 6D).
> 
> Do a search on "DCI" in the Xilinx Answers database for more info.
> 
> Hope this is helpful.

Article: 100965
Subject: Re: Xilinx DCI resistor placement guidelines
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Fri, 21 Apr 2006 12:34:20 -0700
Links: << >>  << T >>  << A >>
Hi - 

On Fri, 21 Apr 2006 11:00:08 -0700, mr_dsp@myrealbox.com wrote:

>On 17 Apr 2006 22:03:58 -0700, "Andrew FPGA"
><andrew.newsgroup@gmail.com> wrote:
>
>>Hi,
>>I have been unable to find any info/guidelines for PCB placement of the
>>DCI reference resistors. I.e. the resistors that attach to VRN and VRP.
>> My instinct says decoupling capacitors highest priority (closest to
>>FPGA package), DCI resistors next priority, and everything else lowest
>>priority.
>>
>>How senstive to noise are the VRP/VRN inputs?
>>
>>FPGA is XC3S200-4FT256 and I'm using 49R9 DCI reference resistors.
>>
>>Regards
>>Andrew
>
>Great resource for decoupling cap placement and component priorities:
>
>http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf
>
>According to this power distribution app note, page 12, placement of
>termination resistors  takes precedence over decoupling caps.  The DCI
>reference resistors function like termination resistors.

I don't think that this is the case.  These resistors are not
terminating a trace in any conventional sense; instead, they're acting
as half of a resistive divider, the other half consisting of the
N-channel or P-channel transistors inside the FPGA.  The DCI cal
circuit is looking at the voltage level on the DCI reference pin when
the cal driver is on, to get an idea of whether the driver is higher
or lower than the required impedance.  It adjusts the driver impedance
up or down based on the voltage it sees.

I certainly wouldn't put these resistors too far away; you don't want
noise coupling into the traces when the FPGA is trying to make a
calibration measurement.  But the distance shouldn't be
super-critical, either.

Bob Perlman
Cambrian Design Works

 

Article: 100966
Subject: XST pre-defined macros
From: "Jeff Brower" <jbrower@signalogic.com>
Date: 21 Apr 2006 13:15:01 -0700
Links: << >>  << T >>  << A >>
All-

Does XST provide any pre-defined macros or constants?  For example:

  __BUILD_NUMBER
  __XST_VER

that could be used in source code as contents of a logic revision
register, or could be used to know which version of XST is in use?

If this is not available, is there a way to kludge it that's
"relatively automatic"?

To Xilinx:  I know that "ISE ain't Visual Studio", but helpful code
maintenance items such as this could easily be implemented.

-Jeff


Article: 100967
Subject: Re: EDK : FSL macros defined by Xilinx are wrong
From: Sylvain Munaut <tnt-at-246tNt-dot-com@youknowwhattodo.com>
Date: Fri, 21 Apr 2006 22:18:25 +0200
Links: << >>  << T >>  << A >>
Can anyone @Xilinx can confirm they read this and will take
care of it ?


Sylvain Munaut wrote:
> Hi everyone,
> 
> I hope someone @Xilinx will read this.
> 
> In the new EDK 8.1 the FSL access macros have changed
> name. And they also introduced _interruptible versions.
> Theses are defined in
> ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h
> 
> The definitions for getfsl_interruptible and
> cgetfsl_interruptible are correct. But the ones for
> putfsl_interruptible and cputfsl_interruptible are
> incorrect. For example putfsl_interruptible is :
> 
> #define putfsl_interruptible(val, id)    \
>    asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>                  "addic\tr18,r0,0\n\t"              \
>                  "bnei\tr18,1b\n"                   \
>                  : "=d" (val) :: "r18")
> 
> and it should be :
> 
> #define putfsl_interruptible(val, id)    \
>    asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>                  "addic\tr18,r0,0\n\t"              \
>                  "bnei\tr18,1b\n"                   \
>                  :: "d" (val) : "r18")
> 
> Obviously val is a input in the case of a 'put' and not
> an output.
> 
> 
> Another related question : In my code, when a replace all
> non _interruptible versions by their _interruptible counter
> parts, it doesn't behave as excpected anymore ...
> Does theses version require some hw support ?
> 
> 
> 
> Sylvain
> 
> 
> 
> PS: I know I should submit a webcase but when I try to login
> I just get "Server Error" ... and so I obviously can't even
> submit a webcase about my problem of being unable to log in
> into the webcase ...

Article: 100968
Subject: Re: EDK : FSL macros defined by Xilinx are wrong
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 21 Apr 2006 13:56:55 -0700
Links: << >>  << T >>  << A >>
Sylvain,

I got it.

I will find out what happened, and report back.

Thanks,

Austin

Sylvain Munaut wrote:

> Can anyone @Xilinx can confirm they read this and will take
> care of it ?
> 
> 
> Sylvain Munaut wrote:
> 
>> Hi everyone,
>>
>> I hope someone @Xilinx will read this.
>>
>> In the new EDK 8.1 the FSL access macros have changed
>> name. And they also introduced _interruptible versions.
>> Theses are defined in
>> ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h
>>
>> The definitions for getfsl_interruptible and
>> cgetfsl_interruptible are correct. But the ones for
>> putfsl_interruptible and cputfsl_interruptible are
>> incorrect. For example putfsl_interruptible is :
>>
>> #define putfsl_interruptible(val, id)    \
>>    asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>>                  "addic\tr18,r0,0\n\t"              \
>>                  "bnei\tr18,1b\n"                   \
>>                  : "=d" (val) :: "r18")
>>
>> and it should be :
>>
>> #define putfsl_interruptible(val, id)    \
>>    asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>>                  "addic\tr18,r0,0\n\t"              \
>>                  "bnei\tr18,1b\n"                   \
>>                  :: "d" (val) : "r18")
>>
>> Obviously val is a input in the case of a 'put' and not
>> an output.
>>
>>
>> Another related question : In my code, when a replace all
>> non _interruptible versions by their _interruptible counter
>> parts, it doesn't behave as excpected anymore ...
>> Does theses version require some hw support ?
>>
>>
>>
>> Sylvain
>>
>>
>>
>> PS: I know I should submit a webcase but when I try to login
>> I just get "Server Error" ... and so I obviously can't even
>> submit a webcase about my problem of being unable to log in
>> into the webcase ...

Article: 100969
Subject: Re: EDK : FSL macros defined by Xilinx are wrong
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 21 Apr 2006 15:49:56 -0700
Links: << >>  << T >>  << A >>
All,

Here is the answer:

"Hi,

Yes this is a bug. This issue is being fixed for the next EDK release
(8.2i). Also, your patches seem correct."

Austin

Austin Lesea wrote:

> Sylvain,
> 
> I got it.
> 
> I will find out what happened, and report back.
> 
> Thanks,
> 
> Austin
> 
> Sylvain Munaut wrote:
> 
>> Can anyone @Xilinx can confirm they read this and will take
>> care of it ?
>>
>>
>> Sylvain Munaut wrote:
>>
>>> Hi everyone,
>>>
>>> I hope someone @Xilinx will read this.
>>>
>>> In the new EDK 8.1 the FSL access macros have changed
>>> name. And they also introduced _interruptible versions.
>>> Theses are defined in
>>> ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h
>>>
>>> The definitions for getfsl_interruptible and
>>> cgetfsl_interruptible are correct. But the ones for
>>> putfsl_interruptible and cputfsl_interruptible are
>>> incorrect. For example putfsl_interruptible is :
>>>
>>> #define putfsl_interruptible(val, id)    \
>>>    asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>>>                  "addic\tr18,r0,0\n\t"              \
>>>                  "bnei\tr18,1b\n"                   \
>>>                  : "=d" (val) :: "r18")
>>>
>>> and it should be :
>>>
>>> #define putfsl_interruptible(val, id)    \
>>>    asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>>>                  "addic\tr18,r0,0\n\t"              \
>>>                  "bnei\tr18,1b\n"                   \
>>>                  :: "d" (val) : "r18")
>>>
>>> Obviously val is a input in the case of a 'put' and not
>>> an output.
>>>
>>>
>>> Another related question : In my code, when a replace all
>>> non _interruptible versions by their _interruptible counter
>>> parts, it doesn't behave as excpected anymore ...
>>> Does theses version require some hw support ?
>>>
>>>
>>>
>>> Sylvain
>>>
>>>
>>>
>>> PS: I know I should submit a webcase but when I try to login
>>> I just get "Server Error" ... and so I obviously can't even
>>> submit a webcase about my problem of being unable to log in
>>> into the webcase ...

Article: 100970
Subject: altera async fifo with different read/write port widths?
From: "fpgabuilder" <fpgabuilder-groups@yahoo.com>
Date: 21 Apr 2006 16:32:04 -0700
Links: << >>  << T >>  << A >>
Does anyone know if Altera has any prebuilt async fifo with different
read/write ports?  I am trying to target Cyclone device.  The M4K
blocks do allow variable width read/write ports but I cannot see any
fifos made using those.

TIA


Article: 100971
Subject: Re: altera async fifo with different read/write port widths?
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 22 Apr 2006 01:27:58 GMT
Links: << >>  << T >>  << A >>
Try the lpm_fifo MegaWizard function.  You can use separate read and write 
ports that are driven from two different unsynchronized clocks.

"fpgabuilder" <fpgabuilder-groups@yahoo.com> wrote in message 
news:1145662324.330234.23380@u72g2000cwu.googlegroups.com...
> Does anyone know if Altera has any prebuilt async fifo with different
> read/write ports?  I am trying to target Cyclone device.  The M4K
> blocks do allow variable width read/write ports but I cannot see any
> fifos made using those.
>
> TIA
> 



Article: 100972
Subject: Tcl used in Modelsim?
From: "Davy" <zhushenli@gmail.com>
Date: 21 Apr 2006 19:34:10 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am new to Modelsim and always use GUI to do all the work.

I heard that we can use Tcl to control Modelsim to compile and run a
batch of work, is there any example available?

BTW, I use Verilog.

Any suggestions will be appreciated!
Davy


Article: 100973
Subject: Re: Initializing array of BlockRAM instances in verilog
From: "Allan" <allanca@gmail.com>
Date: 21 Apr 2006 20:51:28 -0700
Links: << >>  << T >>  << A >>
Nope, that didn't do it either. I've tried some iterations of this
theme with no success. Where would I find the libraries you mentioned
to take a look at?


Article: 100974
Subject: Re: Bluetooth with FPGA?????
From: Eric Smith <eric@brouhaha.com>
Date: 21 Apr 2006 21:08:49 -0700
Links: << >>  << T >>  << A >>
"aymmmm@gmail.com" <aymmmm@gmail.com> writes:
> The final stage is to interface the Spartan-3 to a USB Bluetooth dongle
> to support wireless voice and/or data communications modulated with
> DSSS (IS-95 CDMA).
> 
> I need to interface the USB dongle to the PS/2 port of Spartan-3 using
> a PS/2-to-USB converter.

Sorry, it's not going to work.  USB-to-PS/2B converters only support
PS/2 keyboards, mice, and similar devices on USB hosts.  They don't let
PS/2 hosts talk to arbitrary USB devices such as Bluetooth dongles.



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