EDK : FSL macros defined by Xilinx are wrong

[Jeff Cunningham]

DGerimi@googlemail.com wrote:

Hi,
i have been reading the VHDL language over the last week and now i
want to put what i have learned so far into practice but don't know
really from where to start. As such, i am just wondering if there is
any lab book or a web based tutorials that help a newbie like me to
gradually get a grip on vhdl design techniques on FPGA. I am seeking
any series of recommended labs to proceed through (one after one)

Many thanks

I would suggest downloading the modelsim xilinx starter edition (XSE)
from the xilinx website. Then you can try things and simulate them and
see the result. You could also download the xilinx webpack tools so you
can synthesize your designs to see how big/fast they are. I think there
are tutorials/examples that come with webpack but I could be wrong.

 

[Symon]

Try contributing to this:-
http://wiki.duskglow.com/tiki-index.php?page=open-graphics
Plenty of opportunity for BS. ;-)
HTH, Syms.

 

[Daniel]

Did someone have a realistic gate count for jbig on an fgpa?

 

[lyra]

Can someone help?

"lyra" <ss_chen@csmsc.com> Đ´ČëĎűϢĐÂÎĹ:f4ai3m$5av$1@news.cn99.com...

Hi, All,

I face a program error and can not solve it. Pls you help me if you know
how.

Below is detailed info and you can see attachment for screenshot. Thank
you.
{ chip:Stratix 2--EP2S15F484I4
Hardware Setup: ByteBlaster[LPT1] Mode:Active Serial Programming
error information:current programming hardware does not support Active
Serial Programming programming mode}

Best Regards
Peter

 

On Jun 10, 8:22 pm, "lyra" <ss_c...@csmsc.com> wrote:

I face a program error and can not solve it. Pls you help me if you know
how.

{ chip:Stratix 2--EP2S15F484I4
Hardware Setup: ByteBlaster[LPT1] Mode:Active Serial Programming
error information:current programming hardware does not support Active
Serial Programming programming mode}

Sure. Use Passive Serial mode or Jtag, depending on what signals you
have hooked up. Active Serial is only for use when the FPGA loads
from certain configuration memories, not when it's loaded with a
programmer cable (the idea is that you want the computer, not the
FPGA, to be clocking the data transfer)

 

[fff]

en français, c'est mieux!

fff.

 

[Terry Brown]

I think Mentor mistakenly thinks that further restricting their licenses
will make customers purchase more expensive licenses because they can't
live without Mentor products.

With the upgrade from Modelsim Designer 6.1f to Modelsim 6.2f, you lose
the ability to run Designer in PE mode--this without any notification,
and without grandfathering in upgrades for existing paying customers at
no charge.

A while ago, they similarly restricted USB based key licenses so that you
couldn't run multiple copies on a single machine, even if you did have
valid licenses and keys.

I'm going to switch to Riviera--Linux versions at reasonable pricing,
nearly twice as fast as Modelsim PE, and hungry enough to actually think
the customer might need real support.

Terry Brown

On Wed, 27 Jun 2007 17:11:55 -0700, Xilinx User wrote:

I upgraded my Modelsim XE-III 6.2c starter edition to Modelsm XE-III
6.2g starter edition. Before isntalling the new software, I uninstalled
6.2c (from Control Panel), and then I deleted the
\modelsim_xe_starter directory on my hard-drive.

After the upgrade, I recycled the license.dat file from the old modelsim
starter edition. (The license checker says it's valid.) I tried running
some Systemverilog testbenches I had... all of them produce the same
fatal error. I can compile the code without problem. But when I try to
start the simulation (using the 'vsim' command from the Modelsim
command-line), I get the following error message:

\modelsiim_xe_starter\win32xeoem/../sv_std is not compiled with XE
simulator.

My Systemverilog testbenches have a combination of Verilog-2001 and
Systemverilog modules, but I tried a simple testcase with just a single
Systemverilog module -- same problem. This was just a simple .sv file
with an interface declaration (but no 'advanced' features that require
the Questa license.) I also compiled a simple (single-file) VHDL
testbench and (single-file) Verilog-2001 testbench. Both compiled and
simulated just fine.

i was going to suggest buying a few XE-III (full) licenses, but that was
contingent upon, apparently, an undocumented/unofficial support for
Systemverilog. Now, I'll probably suggest getting (Mentor) Modelsim-PE.

Anyway, Modelsim XE-III 6.2c starter-edition ran Systemverilog
simulations just fine. So did Xilinx remove this feature from XE-III
6.2g? Nowhere in Xilinx's online documentation, does Xilinx claim to
support Systemverilog. But I'd like to get a definitive/official
answer.

 

[Jon Beniston]

always @(posedge clk)
begin

if (ce)
q <= d;

end

Omitting an else here is fine if you ask me.

Cheers,
Jon

 

[devices]

"Jon Beniston" <jon@beniston.com> wrote in message
news:1183133181.732700.262600@q69g2000hsb.googlegroups.com...

always @(posedge clk)
begin

if (ce)
q <= d;

end

Omitting an else here is fine if you ask me.

Cheers,
Jon

Thanks

 

[Bob Perlman]

Hi -

Can you tell us a bit more about your requirements? In particular:

- What clock frequency are you distributing?

- What are your synchronization requirements?

- Do you plan to have synchronous buses or signals running between
the FPGAs? What frequency are they running at?

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com


On Thu, 12 Jul 2007 17:56:19 +0200, "Geronimo Stempovski"
<geronimo.stempovski@arcor.de> wrote:

Hi folks,

I am planning to design a PCB featuring three Virtex-4 FX60 FPGAs and some
periphery. The three FPGAs are needed due to the data processing complexity
and the amount of high-speed IOs (MGTs). What I am most concerned about
right now is to find an appropriate clocking solution.

In my opinion, there are mainly three alternatives to design the clocking
scheme:

a) connection of the clock in a star-like topology, feeding each of the
three FPGAs with the same clock signal (which has to be possibly duplicated
by a clock buffer to generate three out of one clock reference signal,
thereby introducing additional jitter)

b) clock in daisy-chain, feeding each of the three FPGAs with the identical
clock signal which is routed from one device to another (in terms of jitter
this is also not an optimal solution)

c) each FPGA device is supplied with its own clock (which than can be
optimally routed to the device in short distances), but synchronization is a
major issue then

Does anyone have sufficient experience in designing clock trees and is
willing to share his experience, comments, hints and suggestions with me?

Thanks in advance

Gero

 

[austin]

Bob,

Good point: depending on his requirements, he may have to BOTH send a
high quality, low jitter clock to all FPGAs, AND forward clocks from
each FPGA to other ones for source synchronous transfer operation on his
communications between devices.

Austin

 

On Jul 12, 11:56 am, "Geronimo Stempovski"
<geronimo.stempov...@arcor.de> wrote:

Hi folks,

I am planning to design a PCB featuring three Virtex-4 FX60 FPGAs and some
periphery. The three FPGAs are needed due to the data processing complexity
and the amount of high-speed IOs (MGTs). What I am most concerned about
right now is to find an appropriate clocking solution.

In my opinion, there are mainly three alternatives to design the clocking
scheme:

a) connection of the clock in a star-like topology, feeding each of the
three FPGAs with the same clock signal (which has to be possibly duplicated
by a clock buffer to generate three out of one clock reference signal,
thereby introducing additional jitter)

b) clock in daisy-chain, feeding each of the three FPGAs with the identical
clock signal which is routed from one device to another (in terms of jitter
this is also not an optimal solution)

c) each FPGA device is supplied with its own clock (which than can be
optimally routed to the device in short distances), but synchronization is a
major issue then

Does anyone have sufficient experience in designing clock trees and is
willing to share his experience, comments, hints and suggestions with me?

Thanks in advance

Gero

Don't want to be too salesy - but why not take a look at Lattice Clock
Manager devices - very high performance, very low jitter, and per pin
voltage, termination, and skew control - just the ticket for FPGAs
without PLLs ;-)

http://www.latticesemi.com/products/ispclock/index.cfm?source=topnav&jsessionid=ba30b6308a23$24$03$3

(of course, our ECP2M FPGA family might also be of interest ;-) )

hope the design goes well -

Mike Thomas
lattice SFAE NY/NJ

 

[Geronimo Stempovski]

Okay, let's be more precise: The clock frequencies I'd like to distribute
are in the range of 180 - 300 MHz, i.e. it is a challenging task. The signal
busses between the FPGAs should carry signals in that range, too. Data is
exchanged synchronously, so there is not much room for synchronization I
think...!?

Gero

 

[RCIngham]

Tanks for your answers so far!

Oay, to make it more precise: I'm looking for an interconnect system
(multi-channel plug + receptacle) for 24 differential pairs at signaling

rates of 3 - 6 Gbps per channel.

That is an astonishingly high data rate (~70 Gbps to ~150 Gbps)! I won't

ask what it's for, as I suspect you wouldn't be able to tell us. ;-)

How far is the system architecture defined? Instead of a 'Digital' board +
'DAC' board, could you do it with a series of 'Digital + DAC' slices, even
if that meant replicating some of the functions in each slice?

On a previous project, the high potential interconnection data rates
rendered the 'obvious' approach non-viable, and so a more
communication-friendly architecture had to be developed.

 

[Symon]

"Maurice Branson" <traubenuss@arcor.de> wrote in message
news:46971c5b$0$3830$9b4e6d93@newsspool4.arcor-online.net...

Tanks for your answers so far!

Oay, to make it more precise: I'm looking for an interconnect system
(multi-channel plug + receptacle) for 24 differential pairs at signaling
rates of 3 - 6 Gbps per channel.


Hi Maurice,

Dunno if this fits your requirements, but these are cheap and v. fast. Maybe
20Gb/s.
http://www.samtec.com/ftppub/testrpt/hsc-report_sal1-bottom-entry_web.pdf
HTH, Syms.
p.s. Looks like 'bottom entry' is the way to go!

 

[Symon]

"Geronimo Stempovski" <geronimo.stempovski@arcor.de> wrote in message
news:46964f24$0$3841$9b4e6d93@newsspool4.arcor-online.net...

Hi folks,

I am planning to design a PCB featuring three Virtex-4 FX60 FPGAs and some
periphery. The three FPGAs are needed due to the data processing
complexity and the amount of high-speed IOs (MGTs). What I am most
concerned about right now is to find an appropriate clocking solution.

In my opinion, there are mainly three alternatives to design the clocking
scheme:

a) connection of the clock in a star-like topology, feeding each of the
three FPGAs with the same clock signal (which has to be possibly
duplicated by a clock buffer to generate three out of one clock reference
signal, thereby introducing additional jitter)

Hi Geronimo,

This alternative will work. You should use a clock buffer to duplicate your
clock three times.. The amount of jitter is generates will be at least an
order of magnitude less than the jitter introduced just getting on to the
FPGAs' internal clock trees.

b) clock in daisy-chain, feeding each of the three FPGAs with the
identical clock signal which is routed from one device to another (in
terms of jitter this is also not an optimal solution)

You might also consider source synchronous busses to get data between FPGAs

in addition to the star topology.

c) each FPGA device is supplied with its own clock (which than can be
optimally routed to the device in short distances), but synchronization is
a major issue then

I see no advantages in using this third method.

Does anyone have sufficient experience in designing clock trees and is
willing to share his experience, comments, hints and suggestions with me?

Thanks in advance

Gero

It's hard to advise you without a specific set of requirements, but I'd say

your design stands a good chance of success simply because you're thinking
hard about this up front!
HTH., Syms.