Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 122500

Article: 122500
Subject: Re: ERROR:NgdBuild:927 - Failed to process BMM file edkBmmFile.bmm
From: Guy_FPGA <guybye@hotmail.com>
Date: Sun, 29 Jul 2007 04:03:32 -0700
Links: << >>  << T >>  << A >>
Hi Fatih Gunes

You didn't supply enough information, I assume that your xmp project
is a subsystem.
Please look inside you xps project folder/implementation/
system_stub.bmm.(this file must be added to your ise project)please
verify that the instantiation of the processor there (system_i),
mateches the one in the system's hdl top level.

Hope i was clear enough.

anyway please check the following link,
http://www.xilinx.com/publications/xcellonline/xcell_52/xc_synplify52.htm

Pay a special attnetion to "ProjNav ISE Flow"..


Hope I was clear enough, if not then do not hesitate to reply..

Regards,

Guy Zur

Hardware Engineer.


Article: 122501
Subject: Re: Best CPU platform(s) for FPGA synthesis
From: PFC <lists@peufeu.com>
Date: Sun, 29 Jul 2007 13:12:04 +0200
Links: << >>  << T >>  << A >>

>> 3 GB is a practical limit because the PCI bus and other memory-mapped
>> devices typically occupy some hundred megabytes of address space. So you
>> can't use this memory space to access RAM.

> These are usually not mapped into the address space of a user process.

	Nope, but the (32-bit) kernel needs to see the mmap'ed peripherals + the  
userspace RAM if implementation of stuff like file reading, etc is to be  
efficient (without juggling with pages)...

Article: 122502
Subject: Re: dual port ram
From: Andy Botterill <andy@plymouth2.demon.co.uk>
Date: Sun, 29 Jul 2007 13:48:53 +0100
Links: << >>  << T >>  << A >>
Err I only have 3 registers that I must have a reset state for. This 
should fit well with what you have described. I am trying to code that 
up at the moment.

The point of this exercise is to get a cycle accurate operation for a 
register version and a dual port ram version. After that I will look at 
gate count and or speed.

The issues that I had with not being able to create small dual port rams 
was selft inflicted. I put the source code into the library when I 
didn't intend to.  OOps.

-- Andy

Jonathan Bromley wrote:
> On Sat, 28 Jul 2007 19:06:06 -0500, Ben Jackson <ben@ben.com> wrote:
> 
> 
>>On 2007-07-28, Jonathan Bromley wrote:
>>
>>>HOWEVER, you *can* initialise the contents of any Xilinx
>>>RAM at configuration
>>
>>But then you can't just 'reset' your design.  You have to
>>reconfigure from the bitstream to truly reset.
> 
> 
> Yes.  But the solution I offered - one "I have been written"
> register bit per RAM location - doesn't scale well; it's fine
> for up to a few dozen locations, no more.
> 
> If you can arrange that the RAM locations whose initial value
> matters to you are all in a small piece of address space, you
> can easily modify the "I have been written" trick so that
> it applies only to the small part of the memory that has the
> initialisation requirement.
> 
> More generally, it is not unreasonable to consider modifying
> your system's control state machine so that its first action
> after reset is to scribble the initialisation values into RAM,
> maybe by block-copy out of another memory configured as ROM
> with the reset values in it.
> 
> As Peter said, it's not practical to reset a big memory,
> and people have lived with this for ever.

Article: 122503
Subject: Re: completely open source fpga toolchain
From: fpga_toys@yahoo.com
Date: Sun, 29 Jul 2007 08:54:34 -0700
Links: << >>  << T >>  << A >>
On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote:
> They used Icarus Verilog for synthesis. Synthesis capability has been
> removed from icarus Verilog (though the author hopes to reintegrate it
> one day) since it was very broken and buggy.

That's excessively harsh, and equally said of vendors tools with all
the bugs they have. There have been enough threads go thru here about
those too. So if this is just more open source bashing, please be more
specific, and things will get fixed.

Steve (the author of icarus Verilog) does admit that synthesis in the
current 0.9 development branch is broken right now, due to some major
internal changes in progress, but will be fixed after the 0.9 release
is done. During that transition he expects people can continue to use
0.8 synthesis until it's fixed for 0.9.

I'm sure that if you actually report what you think is "very broken
and buggy" problems, fixes will appear when he (or others) have time.
That that much time between fixes we see for vendors tools which
appear at major release cycles.

Steve reports there are others, besides him, working on synthesis
backends, and when he gets fixes, he generally applies them to the
release tree.



Article: 122504
Subject: Re: completely open source fpga toolchain
From: fpga_toys@yahoo.com
Date: Sun, 29 Jul 2007 09:08:03 -0700
Links: << >>  << T >>  << A >>
On Jul 29, 9:54 am, fpga_t...@yahoo.com wrote:
> On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote:
>
> > They used Icarus Verilog for synthesis. Synthesis capability has been
> > removed from icarus Verilog (though the author hopes to reintegrate it
> > one day) since it was very broken and buggy.

> Steve (the author of icarus Verilog) does admit that synthesis in the
> current 0.9 development branch is broken right now, due to some major
> internal changes in progress, but will be fixed after the 0.9 release
> is done. During that transition he expects people can continue to use
> 0.8 synthesis until it's fixed for 0.9.

Oh ... two other notes ... at least in progress development trees are
visible and available with open source projects, and you can certainly
fix problems you find and contribute to the project when you have the
skills and time.

Like vendors tools, when releases show up with major bugs, you do the
same thing ... keep using the previous release until another major
release rolls that you can use (or a patch/update appears).


Article: 122505
Subject: Re: dual port ram
From: Ben Jackson <ben@ben.com>
Date: Sun, 29 Jul 2007 13:09:18 -0500
Links: << >>  << T >>  << A >>
On 2007-07-29, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:
> On Sat, 28 Jul 2007 19:06:06 -0500, Ben Jackson <ben@ben.com> wrote:
>
>>On 2007-07-28, Jonathan Bromley wrote:
>>> HOWEVER, you *can* initialise the contents of any Xilinx
>>> RAM at configuration
>>
>> But then you can't just 'reset' your design.  You have to
>> reconfigure from the bitstream to truly reset.
>
> As Peter said, it's not practical to reset a big memory,
> and people have lived with this for ever.

I just wanted the OP to realize the significant tradeoff he's making
by using preloaded blockrams.  If you 'reset' a design that uses them
you'll be surprised if you expected the reset values to appear in the
RAM again!

For something like a processor, I might just require a certain instruction
sequence at initialization that sets up the RAMs the way I want.  You'd
be in good company -- good luck executing anything on a modern Intel
processor without following 100 steps in a thick databook...

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 122506
Subject: Simple UDP packets forwarding using lwip sockets
From: ryufrank@hotmail.com
Date: Sun, 29 Jul 2007 12:15:05 -0700
Links: << >>  << T >>  << A >>
Hello. I have just started working with a Virtex 4 board, and I need
to make an application which will be connected on a Gigabit LAN using
its hard TEMAC, collect some data transmitted to it (at highest data
rate possible), store/manipulate them, and the forward them to a
predefined network address.
I will be using UDP protocol for the transmissions, to obtain the
simplest/fastest possible communication.
To give myself a headstart, I started by changing the TCP echo server
provided by my board`s supplier (
www.files.em.avnet.com/files/181/279/fx12_lc_temac_lwip_echo_server_edk9_1_01.zip).

It`s using Socket API, for which while it`s supposed to be simpler
than Raw (i guess), I couldn`t find much information on the internet
to help me work with.
After many attempts, I have removed all my additional code from the
example, and the only modifications left in \echo_sockets\src\socket.c
is:

line 244:    sock = socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP);


I compile everything and download it to the board with no problem, up
to the point I send UDP data to the board.
Nothing happens.
After placing some breakpoints, I discovered that the code doesn`t
appear to manage go through line 262.

line 262:    s = accept(sock,(struct sockaddr*)&rem,&len);

I just need to change this small example for now to have something
working to begin with. I believe there is a very easy solution to the
problem that will make me feel stupid.
Any help/suggestions are welcome.

Thank you


Article: 122507
Subject: Microblaze Interrupt Handler
From: icegray <icegray@gmail.com>
Date: Sun, 29 Jul 2007 15:01:21 -0700
Links: << >>  << T >>  << A >>
Hi All,
I'm beginner for Microblaze. I use Spartan3E eval kit. I want to
create custom ip and use interrupt.
1 - I create custom ip, connect it to OPB then I connect ports. I'm
trying my ip on the board and it is ok. My ip is working without a
problem.

2 - I create a line in mhs file (there is no another interrupt, there
is no interrupt controller on the system) in microblaze block
PORT INTERRUPT = microblaze_0_INTERRUPT
also custom_ip block contains
PORT IP2INTC_Irpt = microblaze_0_INTERRUPT.

3 - I type interrupt handler function name (Software Platform Setting
> Interrupt Handler > Interrupt Handler > MyIntHandler.
After this step I can't build applications and give a message to me
./microblaze_0/lib//libxil.a(microblaze_interrupts_g.o)(.data+0x0):/
cygdrive/d/FPGA/custom_ip/microblaze_0/libsrc/standalone_v1_00_a/src/
microblaze_interrupts_g.c: undefined reference to `IntHandler'
collect2: ld returned 1 exit status
make: *** [TestApp_Memory/executable.elf] Error 1

any body can help me? what are my missing steps? thanks


Article: 122508
Subject: Odelay usage in virtex5
From: "Han Phan" <hphan@barctd.net>
Date: Sun, 29 Jul 2007 17:30:03 -0700
Links: << >>  << T >>  << A >>
I would like to use Odelay primitive to delay a signal generated in the virtex5 fpga fabric. For this I am hoping to use IODELAY as shown below.

mlinit_in_l is the signal I would like to delay it in 75 ps resolution using odelay as it goes out to the fpga.

mlinit_l is supposed to be the delayed signal but the output stays low. Thus it is not working.

I would like to know how I tell the IODELAY primitive about using it as ODELAY and specify 75 ps resolution?

The user's guide does not seem to have a lot of inofrmation about this.

module linit_delay(mlinit_in_l, mlinit_l);

input mlinit_in_l; output mlinit_l;

IODELAY linit_dly1(.DATAOUT(mlinit_l), .C(1'b0), 		 .CE(1'b0), 		 .DATAIN(mlinit_in_l), 		 .IDATAIN(mlinit_l), 		 .INC(1'b0), 		 .ODATAIN (mlinit_in_l), 		 .RST(1'b0), 		 .T(1'b0) 		 ); endmodule

Article: 122509
Subject: Re: Best CPU platform(s) for FPGA synthesis
From: Matthieu <m.a.t.t.h.i.e.u.m.i.c.h.o.n@laposte.net>
Date: Mon, 30 Jul 2007 11:37:39 +0900
Links: << >>  << T >>  << A >>
PFC wrote:
> 
>>> 3 GB is a practical limit because the PCI bus and other memory-mapped
>>> devices typically occupy some hundred megabytes of address space. So you
>>> can't use this memory space to access RAM.
> 
>> These are usually not mapped into the address space of a user process.
> 
>     Nope, but the (32-bit) kernel needs to see the mmap'ed peripherals + 
> the userspace RAM if implementation of stuff like file reading, etc is 
> to be efficient (without juggling with pages)...

Anandtech ran an article which does quite a good job in explaining the 2 
and 3 GB barriers.
http://www.anandtech.com/gadgets/showdoc.aspx?i=3034

Article: 122510
Subject: Re: Odelay usage in virtex5
From: motty <mottoblatto@yahoo.com>
Date: Sun, 29 Jul 2007 20:03:00 -0700
Links: << >>  << T >>  << A >>
I don't see what parameters you are using when you instantiate the
primitive.  Those are very important.  And also:

If the V5 ODELAY is anything like the V4 IDELAY (which it probably is
pretty close to), the 75ps resolution is NOT GUARANTEED on a per-tap
basis.  Basically, the delay over all the taps is fixed at some
number.  For the V4 IDELAY that value is 5ns (200 MHz ref clock
period).  Dividing that by 64 (number of taps) gives you 78.125 ps per
tap.

There is an equation to use for the V4 IDELAY that takes into account
the variable nature of the individual tap delays.  You'd be suprised
at how much +/- there is in each tap.  There is a document that
describes this in detail.  It is XAPP707.  I do NOT know if there is a
similar document for the V5 IDELAY/ODELAY.  It may be that the V5
components don't behave like the V4.  I just don't know.  There is an
equation in the V5 Switching Characteristics Guide, but it may not
give the most accurate answers.

But if they are similar to the V4 primitives, then you can't just use
one tap and be assured that you are getting an exact delay.  You can
always check it on a scope and verify it fits your design.  Then you
are fine...at least for that particular part.


Article: 122511
Subject: Re: Timing simulation
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sun, 29 Jul 2007 21:58:51 -0700
Links: << >>  << T >>  << A >>
Eddie H wrote:


> I have multiple clock domains so I am hoping that it will provide multiple Fmax values.

I would make separate entities for each
clock domain and run STA separately for each.

Then work out synchronization
between the domains.

     -- Mike Treseler

Article: 122512
Subject: Re: Microblaze Interrupt Handler
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 30 Jul 2007 05:08:20 -0000
Links: << >>  << T >>  << A >>
On 30 Jul., 00:01, icegray <iceg...@gmail.com> wrote:
> Hi All,
> I'm beginner for Microblaze. I use Spartan3E eval kit. I want to
> create custom ip and use interrupt.
> 1 - I create custom ip, connect it to OPB then I connect ports. I'm
> trying my ip on the board and it is ok. My ip is working without a
> problem.
>
> 2 - I create a line in mhs file (there is no another interrupt, there
> is no interrupt controller on the system) in microblaze block
> PORT INTERRUPT = microblaze_0_INTERRUPT
> also custom_ip block contains
> PORT IP2INTC_Irpt = microblaze_0_INTERRUPT.
>
> 3 - I type interrupt handler function name (Software Platform Setting> Interrupt Handler > Interrupt Handler > MyIntHandler.
>
> After this step I can't build applications and give a message to me
> ./microblaze_0/lib//libxil.a(microblaze_interrupts_g.o)(.data+0x0):/
> cygdrive/d/FPGA/custom_ip/microblaze_0/libsrc/standalone_v1_00_a/src/
> microblaze_interrupts_g.c: undefined reference to `IntHandler'
> collect2: ld returned 1 exit status
> make: *** [TestApp_Memory/executable.elf] Error 1
>
> any body can help me? what are my missing steps? thanks

try:
1 did you write the code for te inteterrupt handler?
2 start with some demo examples that already use interrupts
3 connect the interrupt from your ip to intc

Antti







Article: 122513
Subject: Re: ERROR:NgdBuild:927 - Failed to process BMM file edkBmmFile.bmm
From: "mfgunes" <mfgunes@yahoo.com>
Date: Mon, 30 Jul 2007 00:15:45 -0500
Links: << >>  << T >>  << A >>
Hi Guy Zur,

Firstly,thank you for your reply.I want to add xmp file to ISE project as 
a sub module.I looked for system_stub but couldnt find.Then i create it and
i paste the content of "system.bmm" to system_stub.So i have to instantiate
microblaze manually.

Have a nice day

Article: 122514
Subject: Re: ERROR:NgdBuild:927 - Failed to process BMM file edkBmmFile.bmm
From: "mfgunes" <mfgunes@yahoo.com>
Date: Mon, 30 Jul 2007 00:26:28 -0500
Links: << >>  << T >>  << A >>
Hi Guy Zur,

Firstly,thank you for your reply.I want to add xmp file to ISE project as 
a sub module.I looked for system_stub but couldnt find.Then i create it and
i paste the content of "system.bmm" to system_stub.So i have to instantiate
microblaze manually.

Have a nice day

Article: 122515
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: colin <colin_toogood@yahoo.com>
Date: Mon, 30 Jul 2007 00:29:05 -0700
Links: << >>  << T >>  << A >>
On 28 Jul, 12:58, "Symon" <symon_bre...@hotmail.com> wrote:
> "colin" <colin_toog...@yahoo.com> wrote in message
>
> news:1185552810.842102.166100@k79g2000hse.googlegroups.com...>I read this thread with great interest and have a very closely related
> > question.
>
> > As of May 07 Altera recommend putting their pll gnd pins in a split
> > plane. The arguments in this thread make a lot of sense for seperate
> > analog circuits being on the same plane because one can physically
> > seperate them, but how about pll gnds which are 3mm (3 balls) away
> > from a standard GND pin.
>
> > Any advice appreciated as this will end an argument in our office.
>
> > Colin
>
> Hi Colin,
> Do you have a link to Altera's recommendation? A picture of what they're
> suggesting would be nice.
>
> Anyway, without having read TFA, I'll spout on regardless!
>
> For there to be noise injected into the supply of the PLL, it would need to
> have noise current from the digital stuff or whatever passing through the
> ground plane between where the PLL ground via(s) attach(es) and where the
> PLL supply bypass capactitor ground via(s) attach(es). Clearly the smaller
> this distance the less voltage is induced in the PLL supply. Bear in mind
> that ground planes have very low impedance.
>
> Now, if the separation between the bypass caps and the PLL ground vias is a
> lot, there might be a problem. However, I'm a skeptic until someone prove
> otherwise. I bet the noise on the supplies is a lot bigger problem than
> noise on a ground plane. (I bet they say to use LDO regs on the supplies,
> even though the B/W of such regs. are a best a few hundred kHz. A passive
> filter is much better!)
>
> HTH., Syms.
> p.s. What's the deal on your office argument? Can you post the opinions?

Syms

Altera's recomendation is on page 27 of http://www.altera.com/literature/hb/stx2/stx2_sii52012.pdf

There are three options floating around here

1) Just tie the pll gnds down to the plane.
2) Split the plane in 1)
3) Route out the net and tie it to the plane at the decoupling
capacitor.

A guy here reckons on 3) regardless of how close one can get the cap.
What he says doesn't feel right but I have no idea what sort of
frequencies flow through a pll gnd pin and therefore whether the
inductance on the net matters.

Colin




Article: 122516
Subject: Re: Can multiple Ferrite Beads be used to connect ...?
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 30 Jul 2007 10:40:52 +0100
Links: << >>  << T >>  << A >>

"colin" <colin_toogood@yahoo.com> wrote in message 
news:1185780545.905561.144730@57g2000hsv.googlegroups.com...
> On 28 Jul, 12:58, "Symon" <symon_bre...@hotmail.com> wrote:
>> "colin" <colin_toog...@yahoo.com> wrote in message
>>
>> news:1185552810.842102.166100@k79g2000hse.googlegroups.com...>I read this 
>> thread with great interest and have a very closely related
>> > question.
>>
>> > As of May 07 Altera recommend putting their pll gnd pins in a split
>> > plane. The arguments in this thread make a lot of sense for seperate
>> > analog circuits being on the same plane because one can physically
>> > seperate them, but how about pll gnds which are 3mm (3 balls) away
>> > from a standard GND pin.
>>
>> > Any advice appreciated as this will end an argument in our office.
>>
>> > Colin
>>
>> Hi Colin,
>> Do you have a link to Altera's recommendation? A picture of what they're
>> suggesting would be nice.
>>
>> Anyway, without having read TFA, I'll spout on regardless!
>>
>> For there to be noise injected into the supply of the PLL, it would need 
>> to
>> have noise current from the digital stuff or whatever passing through the
>> ground plane between where the PLL ground via(s) attach(es) and where the
>> PLL supply bypass capactitor ground via(s) attach(es). Clearly the 
>> smaller
>> this distance the less voltage is induced in the PLL supply. Bear in mind
>> that ground planes have very low impedance.
>>
>> Now, if the separation between the bypass caps and the PLL ground vias is 
>> a
>> lot, there might be a problem. However, I'm a skeptic until someone prove
>> otherwise. I bet the noise on the supplies is a lot bigger problem than
>> noise on a ground plane. (I bet they say to use LDO regs on the supplies,
>> even though the B/W of such regs. are a best a few hundred kHz. A passive
>> filter is much better!)
>>
>> HTH., Syms.
>> p.s. What's the deal on your office argument? Can you post the opinions?
>
> Syms
>
> Altera's recomendation is on page 27 of 
> http://www.altera.com/literature/hb/stx2/stx2_sii52012.pdf
>
> There are three options floating around here
>
> 1) Just tie the pll gnds down to the plane.
> 2) Split the plane in 1)
> 3) Route out the net and tie it to the plane at the decoupling
> capacitor.
>
> A guy here reckons on 3) regardless of how close one can get the cap.
> What he says doesn't feel right but I have no idea what sort of
> frequencies flow through a pll gnd pin and therefore whether the
> inductance on the net matters.
>
> Colin
>
Hi Colin,
Thanks for the link. Sadly, it's yet another "[Our company] recommends using 
separate analog and digital power [and ground] planes." without any 
explanation or justification. I guess because they have no explanation or 
justification. Except for the "monkeys hose water ladder banana" one. ;-) 
(Google it!) Of course, separate (or non-overlapping) power planes are a 
good idea, but that doesn't mean that separate ground planes are.

I also read http://www.altera.com/literature/hb/sgx/sgx_sgx53001.pdf page 
31, where they at least mention that there are supporters of the solid 
ground method. They then proceed to do some (IMO) bogus experiment where 
they build a board with ground islands separated by ferrite beads. They then 
repeat the expeiment with the beads "shorted to a wire" (sic). What? They 
apparently claim that the ferrites are better than wire, although they 
publish no data except that "The tests showed a jitter improvement of 
approximately 10% when isolating the ground planes.", implying that bits of 
wire here and there are equivalent to a continuous ground plane. What a 
crock! What sort of jitter? Pk-pk? RMS? Why don't they build a board with a 
proper ground plane?

OK, now on to your colleague's idea. In order for his solution (3) to be 
better than (1), there has to be aggressor current flowing through the 
ground plane in (1) between the vias that connect to the ground ball and the 
decoupling capacitor to generate noise on the supply. Note that the ground 
plane has a very low impedance, so you'd need a lot of current for a little 
noise. Also, in order for this current to be in this region of the ground 
plane, the trace carrying the return current would need to be adjacent.

This noise has to be worse than the drop in performance from the increased 
power supply inductance you have in solution (3). If this inductance wasn't 
important, you could make the traces as long as you wanted. (I'd guess the 
inductance due to the traces doubles, in (3) compared to (1), although it 
depends, of course, on how it's routed.) Also, solution (3) could suffer 
from crosstalk from traces that travel near this ground trace. Indeed, all 
things being equal, the aggressor current in the ground plane and the 
adjacent return path that was the problem with (1) can crosstalk* into the 
(3) ground trace.

Anyway, _IMO_ the reason these madcap schemes persist is that, done 
properly**, they all work. However, the problem with modern FPGA circuits 
isn't noise in the ground planes, it's noise in the supplies. I concentrate 
my efforts on this supply noise, leaving my rock hard ground planes to take 
care of business at zero volts, halving my problem.

HTH., Syms.

* Here's an article about crosstalk. 
download.intel.com/education/highered/signal/ELCT762/class19_Crosstalk_overview.ppt

** NB. Split plane or routed ground systems are much easier to to wrongly 
than a solid ground plane.





Article: 122517
Subject: Re: completely open source fpga toolchain
From: Philipp Klaus Krause <pkk@spth.de>
Date: Mon, 30 Jul 2007 12:28:49 +0200
Links: << >>  << T >>  << A >>
fpga_toys@yahoo.com schrieb:
> On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote:
>> They used Icarus Verilog for synthesis. Synthesis capability has been
>> removed from icarus Verilog (though the author hopes to reintegrate it
>> one day) since it was very broken and buggy.
> 
> That's excessively harsh, and equally said of vendors tools with all
> the bugs they have. There have been enough threads go thru here about
> those too. So if this is just more open source bashing, please be more
> specific, and things will get fixed.
> 
> Steve (the author of icarus Verilog) does admit that synthesis in the
> current 0.9 development branch is broken right now, due to some major
> internal changes in progress, but will be fixed after the 0.9 release
> is done. During that transition he expects people can continue to use
> 0.8 synthesis until it's fixed for 0.9.


I remembered 463A2014.7040400@icarus.com, where Steve said:

"CAVEAT: Synthesis in the devel trunk is broken, and has been
temporarily abandoned. There was until very recently precious
little interest in synthesis, so I didn't let it get in the way
of the other tasks I've been working on. Getting synthesis back
on line with the devel branch should be a big job.

Therefore, for now I recommend using the 0.8 branch for synthesis
work, at least for a proof of concept. If there is interest in
putting serious work into it, then getting 0.9 synthesis together
can be worked out later."

> [...]
> Steve reports there are others, besides him, working on synthesis
> backends, and when he gets fixes, he generally applies them to the
> release tree.
>

This is good news, I didn't know that people are working on synthesis
backends. Was there a post on geda-user about it?

Philipp

Article: 122518
Subject: Re: completely open source fpga toolchain
From: Antti <Antti.Lukats@googlemail.com>
Date: Mon, 30 Jul 2007 11:08:48 -0000
Links: << >>  << T >>  << A >>
On 30 Jul., 12:28, Philipp Klaus Krause <p...@spth.de> wrote:
> fpga_t...@yahoo.com schrieb:
>
> > On Jul 27, 4:42 am, Philipp Klaus Krause <p...@spth.de> wrote:
> >> They used Icarus Verilog for synthesis. Synthesis capability has been
> >> removed from icarus Verilog (though the author hopes to reintegrate it
> >> one day) since it was very broken and buggy.
>
> > That's excessively harsh, and equally said of vendors tools with all
> > the bugs they have. There have been enough threads go thru here about
> > those too. So if this is just more open source bashing, please be more
> > specific, and things will get fixed.
>
> > Steve (the author of icarus Verilog) does admit that synthesis in the
> > current 0.9 development branch is broken right now, due to some major
> > internal changes in progress, but will be fixed after the 0.9 release
> > is done. During that transition he expects people can continue to use
> > 0.8 synthesis until it's fixed for 0.9.
>
> I remembered 463A2014.7040...@icarus.com, where Steve said:
>
> "CAVEAT: Synthesis in the devel trunk is broken, and has been
> temporarily abandoned. There was until very recently precious
> little interest in synthesis, so I didn't let it get in the way
> of the other tasks I've been working on. Getting synthesis back
> on line with the devel branch should be a big job.
>
> Therefore, for now I recommend using the 0.8 branch for synthesis
> work, at least for a proof of concept. If there is interest in
> putting serious work into it, then getting 0.9 synthesis together
> can be worked out later."
>
> > [...]
> > Steve reports there are others, besides him, working on synthesis
> > backends, and when he gets fixes, he generally applies them to the
> > release tree.
>
> This is good news, I didn't know that people are working on synthesis
> backends. Was there a post on geda-user about it?
>
> Philipp

there are or have been sure
a while ago I think I got some working AT94K bistream made using the
iverilog front

Antti




Article: 122519
Subject: Re: Microblaze Interrupt Handler
From: icegray <icegray@gmail.com>
Date: Mon, 30 Jul 2007 04:12:24 -0700
Links: << >>  << T >>  << A >>
On Jul 30, 8:08 am, Antti <Antti.Luk...@googlemail.com> wrote:
> On 30 Jul., 00:01, icegray <iceg...@gmail.com> wrote:
>
>
>
>
>
> > Hi All,
> > I'm beginner for Microblaze. I use Spartan3E eval kit. I want to
> > create custom ip and use interrupt.
> > 1 - I create custom ip, connect it to OPB then I connect ports. I'm
> > trying my ip on the board and it is ok. My ip is working without a
> > problem.
>
> > 2 - I create a line in mhs file (there is no another interrupt, there
> > is no interrupt controller on the system) in microblaze block
> > PORT INTERRUPT = microblaze_0_INTERRUPT
> > also custom_ip block contains
> > PORT IP2INTC_Irpt = microblaze_0_INTERRUPT.
>
> > 3 - I type interrupt handler function name (Software Platform Setting> Interrupt Handler > Interrupt Handler > MyIntHandler.
>
> > After this step I can't build applications and give a message to me
> > ./microblaze_0/lib//libxil.a(microblaze_interrupts_g.o)(.data+0x0):/
> > cygdrive/d/FPGA/custom_ip/microblaze_0/libsrc/standalone_v1_00_a/src/
> > microblaze_interrupts_g.c: undefined reference to `IntHandler'
> > collect2: ld returned 1 exit status
> > make: *** [TestApp_Memory/executable.elf] Error 1
>
> > any body can help me? what are my missing steps? thanks
>
> try:
> 1 did you write the code for te inteterrupt handler?
> 2 start with some demo examples that already use interrupts
> 3 connect the interrupt from your ip to intc
>
> Antti- Hide quoted text -
>
> - Show quoted text -

thanks Antti


Article: 122520
Subject: Re: Restricting XST parameter widths from .mpd files?
From: Gabor <gabor@alacron.com>
Date: Mon, 30 Jul 2007 05:20:40 -0700
Links: << >>  << T >>  << A >>
On Jul 28, 8:17 pm, Neil Steiner <neil.stei...@vt.edu> wrote:
> I'm working with a custom verilog core that accepts a small number of
> parameters, and I'm having a hard time pushing them through XST properly
> under EDK 8.1.
>
> For example, I include the following line in my .mpd file:
>
> PARAMETER C_DCR_BASEADDR=0b0001000000, DT=STD_LOGIC_VECTOR, BITWIDTH=10,
> MIN_SIZE=2, BUS=SDCR
>
> But XST happily reports:
>
> C_DCR_BASEADDR = 32'b00000000000000000000000001000000
>
> Does anybody know how to ensure that my C_DCR_BASEADDR parameter is not
> initialized to something wider than 10 bits?


Did you try

C_DCR_BASEADDR=10'b0001000000

Normally verilog assumes integer (32-bit) type for unspecified
bit-widths.  On the other hand are you sure that this matters?
If you assigned the parameter to a 10-bit vector as in

wire [9:0] addr;
assign addr = C_DCR_BASEADDR;

you'd just get the 10 LSB's of the parameter anyway.

HTH,
Gabor


Article: 122521
Subject: Re: Question about Bottom-Up Incremental Compilation Methodology in Quartus II
From: "X.Y." <Xieyu1219@gmail.com>
Date: Mon, 30 Jul 2007 13:11:29 -0000
Links: << >>  << T >>  << A >>
On Jul 28, 6:34 am, Subroto Datta <sda...@altera.com> wrote:
> On Jul 27, 1:25 am, "X.Y." <Xieyu1...@gmail.com> wrote:
>
>
>
>
>
> > On Jul 27, 5:37 am, Subroto Datta <sda...@altera.com> wrote:
>
> > > Hi X.Y,
>
> > > The Incremental Compilation flow currently does not allow the
> > > imported .qxp to be "stamped" onto different instances.  This is
> > > coming.  One workaround is to have a different HDL file and name for
> > > each instance.  Admittedly, this is not ideal but in many cases is an
> > > easy solution.  (If you're making changes on the top-level file, it's
> > > painful to repeat in multiple files.  But if the changes are in the
> > > HDL files beneath that entity, then it all works smoothly after the
> > > initial set-up.)
>
> > > One flow Iused often, mainly because it works and is easy, is the
> > > pseudo-bottom up flow.  This basically involves putting partitions on
> > > the hierarchies that are in the same level as the one/s you are
> > > interested in and set them to Empty(so they have no logic, but nothing
> > > gets removed).  I then work on the partitions I want with quick
> > > compiles.  Then, when I get what I want, I set that partition to post-
> > > fit and either set the other partitions to Source or delete them
> > > altogether(making everything else one big partition).  It's quick and
> > > easy without creating sub-projects, making sure their layout fits into
> > > the top-level, etc.  Also, in Q7.1 you can export a .qxp from sub
> > > partitions, so you can always save off your results.  This works with
> > > multiple instances of the same thing, since they now have different
> > > instances(and locations).
>
> > > What end goal are you using Incremental Compilation flow for?  Are you
> > > trying to reduce compile times, are you trying to preserve
> > > performance, or something else?
>
> > > - Subroto Datta
> > > Altera Corp.
>
> > Thanks for your reply! My end goal is trying to preserve performance.
> > In our project, I use one Cyclone II FPGA to process four groups of
> > image signal which comes from four cameras. The processing algorithms
> > of the four groups of image signal are all the same. As a result, I
> > plan to build a subproject implementing the processing of one of the
> > four signals and export it as a partition. Then, I build a top level
> > project and import it four times. Certainly, I will do four different
> > pin assignments for the four partitions.
> > It appears that LogicLock can do it also, am I right?- Hide quoted text -
>
> > - Show quoted text -
>
> I  would recommend against using LogicLock for preserving
> performance(which is done through back-annotation of location
> assignments).  LogicLock is excellent for floorplanning, but can have
> issues with these back-annotated assignments.  That portion of the
> LogicLock flow is really meant to be replaced by the Incremental
> Compilation flow.
>
> One thing I want to make sure of, does your design not meet timing
> when run flat?  Also, is it large portions of your design or just a
> small sub-section that continually fails timing?  I'm assuming it
> doesn't meet timing when put together, and it's not just a single
> block, as the strategy for these flows can be slightly different.
>
> Do your four equal blocks connect to each other?  Is there some
> central, common logic?  Do they connect to pins?  The problem I've
> seen with what you're trying to do is a good placement of a single
> block isn't good everywhere.  For example, let's say you put them into
> the four quadrants of the device.  In the lower-level you optimize one
> for the top-left corner, so the connections it makes to pins are all
> placed along the top-and-left side, and the connections you make to
> internal logic are on the bottom and right sides.  Now, if you try to
> keep that placement but move it to an instantiation on the bottom-
> right, your pin and logic connections are reversed, and if these paths
> are critical at all, they can fail timing.
>
> Just to go over the pseudo-bottom up flow again, take your top-level
> design and:
>
> 1)  Put a partition on all four instances, and any thing else you want
> to put a partition on.
>
> 2)  Floorplan the partitions(most likely into quadrants) (This is can
> be optional)
>
> 3)  Set three of the four to empty and let the fitter work on the
> fourth one(say top-left region.)
>
> 4)  Set the top-left region to Post-Fit and set a second partition to
> Source(or Post-Synthesis) and fit it
>
> 5)  Repeat onto the third and fourth partition
>
> 6)  If any of them still doesn't make timing, you can back and refit
> that one while leaving the rest post-fit.
>
> The nice thing about this flow is each region is aware of pin
> locations, as well as any logic that is not set to empty.  So if there
> is some central block of logic, it can optimize placement to connect
> to that.  If the pin assignments have a different layour for all four
> instances, the fitter can optimize for that.
>
> Hope this helps,
> Subroto Datta
> Altera Corp.- Hide quoted text -
>
> - Show quoted text -

Hi, Subroto,

Thanks for your reply, I have tried the pseudo-bottom up flow you
recommend. It works well! Once I fit a partition, I can find its
Floorplan Region in Timing Closure Floorplan. At last, there are four
regions for the four partitions.

There are some answers for your questions as flow,
1,  My design doesn't meet timing when run flat.
2,  In my design, the four equal blocks connect to each other.
3,  There is some central, common logic and they connect to pins.

And Besides, there are some questions I want to ask you:
1, What do you mean by "The problem I've seen with what you're trying
to do is a good placement of a single block isn't good everywhere."
2, Actually, in your method, we need to put all the design partitions
in a single Quartus project. The different thing is the compiling flow
you told me. It is not a real bottom up flow (because it involves sub
projects), so you call it pseudo- bottom up flow, am I right?
3, You have ever said " Also, in Q7.1 you can export a .qxp from sub
partitions, so you can always save off your results.  This works with
multiple instances of the same thing, since they now have different
instances (and locations). " in your first letter.  Do you mean, we
can import one sub partition multiple times in Q7.1, however, not in
Q6.0?

Best regards.

Yours sincerely,
X. Y.


Article: 122522
Subject: Re: Odelay usage in virtex5
From: "Han Phan" <>
Date: Mon, 30 Jul 2007 06:13:01 -0700
Links: << >>  << T >>  << A >>
Do I need to use the IDELAYCTRL primitive? Currently I have instantiated the IODELAY primitive only to be used as output delay type. Just using the IODELAY primitive, I am able to do the functional simulation.

But I have a confusion about using the IDELAYCTRL primitive. Is this needed for ODELAY? Or is this only for IDELAY?

I have updated the verilog code based on your input as shown but I am not sure what to do with the IDELAYCTRL primitive

module linit_delay(mlinit_in_l, mlinit_l);

input mlinit_in_l; output mlinit_l;

IODELAY # ( .DELAY_SRC("O"), 	 .IDELAY_TYPE("FIXED"), 	 .IDELAY_VALUE(0), 	 .ODELAY_VALUE(2), 	 .REFCLK_FREQUENCY(200.0) 	 )

linit_dly1 (.DATAOUT(mlinit_l), .C(1'b0), 		 .CE(1'b0), 		 .DATAIN(1'b0), 		 .IDATAIN(1'b0), 		 .INC(1'b0), 		 .ODATAIN(mlinit_in_l), 		 .RST(1'b0), 		 .T(1'b0) 		 ); endmodule

Article: 122523
Subject: Re: Website
From: austin <austin@xilinx.com>
Date: Mon, 30 Jul 2007 07:19:41 -0700
Links: << >>  << T >>  << A >>
Antti,

Again,I need to apologize for the website problems over the weekend.

Please be patient.

Austin

Article: 122524
Subject: Question on using RLOC_RANGE
From: "MM" <mbmsv@yahoo.com>
Date: Mon, 30 Jul 2007 10:20:50 -0400
Links: << >>  << T >>  << A >>
Hi all,

I am trying to tell the ISE tools to place DSP48s belonging to a complex 
multiplier (generated with coregen) close together in a V4FX chip with the 
following line in my UCF:

INST "DUC_BL.DUC_INST/CPL_MPLY_INST/*/mult_2/m18x18/dsp48_?" 
RLOC_RANGE=X1Y1:X1Y3;

I am getting the following error:
------------------
ERROR:Map:10 - RLOC_RANGE attribute on DSP48 symbol
   "DUC_BL.DUC_INST/CPL_MPLY_INST/BU2/U0/mult_2/m18x18/dsp48_0" (output
   signal=DUC_BL.DUC_INST/CPL_MPLY_INST/BU2/U0/p_cout_2<47>) must be on the
   start of a set.


I must admit I have not used RLOC_RANGE before...


Thanks,
/Mikhail





Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search