EDK : FSL macros defined by Xilinx are wrong

[Symon]

Alan Nishioka wrote:

Xilinx is canceling the Virtex-E XCV1000E-FG860.

We are currently shipping a product that uses 13 of these chips on 4
different boards.

Does anyone have any ideas on how to deal with this?

One possibility is to rev the boards to use the XCV1000E-FG900, making
minimal changes to the boards around the fpga.

Complete re-design of the boards for this old system is out of the
question. Stockpiling a bunch of parts won't work because we don't
know what future quantities will be and the parts are very expensive.

Alan Nishioka
alan@nishioka.com

Hi Alan,
Maybe an interposer would work? Mount the FG900 on that, mount the
interposer on your board? Somethign like this...
http://advanced.com/pdf/AIC_BGA_Interposer_DataSheet_revJun07.pdf
HTH., Syms.

 

[Eric Crabill]

Hi,

Crux of the matter: Do you need to define values for outputs of your
state machine in EVERY state, or do you only need to define values
for outputs in states where you want the output to update/change?

It depends on the type of output. If the output is a combinational function
of the current state, or a combinational function of the current state and
the inputs, then you must describe the output values for all possible
conditions. This is how you model combinational logic; it doesn't matter if
it is part of an FSM or not.

On the other hand, if you have outputs which are a registered function of
the current state, or a registered function of the current state and the
inputs, then you do not need to describe the output values for all possible
conditions. Since you will be modeling these assignments to something that
maintains state in a clocked process, using a reg datatype, the absence of
an assignment for a given condition implies "retain the previous value".

Here's a short presentation on a "textbook" FSM:
http://www.engr.sjsu.edu/crabill/vlogfsm.pdf

To paraphrase what someone else wrote, if it solves the problem -- it's
correct. However, I think it's a good practice to fully understand what you
are creating when you write the code solve a given problem.

If you look at the code you provided in the context of a "textbook" FSM, I
would suggest that your FSM state variable is actually more than just
"state". It's
{ackb,cpu_lw_read,cpu_hw_read,cpu_lw_write,cpu_hw_write,state} and by way of
what is a custom state assignment implemented in the next state logic, you
are able to use certain bits of the state directly as outputs (Moore type
outputs) with no combinational decoding logic required to generate those
outputs.

Eric

 

[Eric Crabill]

Hi,

Crux of the matter: Do you need to define values for outputs of your
state machine in EVERY state, or do you only need to define values
for outputs in states where you want the output to update/change?

It depends on the type of output. If the output is a combinational function
of the current state, or a combinational function of the current state and
the inputs, then you must describe the output values for all possible
conditions. This is how you model combinational logic; it doesn't matter if
it is part of an FSM or not.

On the other hand, if you have outputs which are a registered function of
the current state, or a registered function of the current state and the
inputs, then you do not need to describe the output values for all possible
conditions. Since you will be modeling these assignments to something that
maintains state in a clocked process, using a reg datatype, the absence of
an assignment for a given condition implies "retain the previous value".

Here's a short presentation on a "textbook" FSM:
http://www.engr.sjsu.edu/crabill/vlogfsm.pdf

To paraphrase what someone else wrote, if it solves the problem -- it's
correct. However, I think it's a good practice to fully understand what you
are creating when you write the code solve a given problem.

If you look at the code you provided in the context of a "textbook" FSM, I
would suggest that your FSM state variable is actually more than just
"state". It's
{ackb,cpu_lw_read,cpu_hw_read,cpu_lw_write,cpu_hw_write,state} and by way of
what is a custom state assignment implemented in the next state logic, you
are able to use certain bits of the state directly as outputs (Moore type
outputs) with no combinational decoding logic required to generate those
outputs.

Eric

 

[Symon]

Alan Nishioka wrote:

Symon wrote:
Alan Nishioka wrote:
Xilinx is canceling the Virtex-E XCV1000E-FG860.

Maybe an interposer would work? Mount the FG900 on that, mount the
interposer on your board? Something like this...
http://advanced.com/pdf/AIC_BGA_Interposer_DataSheet_revJun07.pdf
HTH., Syms.

I fear that an interposer won't work at 75MHz. It was hard enough to
get to work as it is. But it is worth some thought. I wonder how
much it costs?

Thank you everyone for your responses. I figured it was worth a shot
if anyone had a radical idea.

Alan Nishioka

Hi Alan,

Surprisingly, it may be it works 'better' than the ordinary solution. This
is because the interposer's power planes can be set up differently from the
main PCB's power planes. Whereas the main PCB's power planes are probably a
compromise for the whole circuit, the interposer's planes can be designed to
be optimal for the FPGA. A more expensive stackup can be used as the
interposers are small. Bypass caps can be mounted on the interposer.

Here's a link which explains better than I can.
http://www.samtec.com/sudden_service/current_literature/powerposer.asp

Anyway, good luck with it all, I've been in similar situations myself, and
the usual solution is a redesign. :-(

Best, Syms.

 

[Symon]

Alan Nishioka wrote:

Symon wrote:
Alan Nishioka wrote:
Xilinx is canceling the Virtex-E XCV1000E-FG860.

Maybe an interposer would work? Mount the FG900 on that, mount the
interposer on your board? Something like this...
http://advanced.com/pdf/AIC_BGA_Interposer_DataSheet_revJun07.pdf
HTH., Syms.

I fear that an interposer won't work at 75MHz. It was hard enough to
get to work as it is. But it is worth some thought. I wonder how
much it costs?

Thank you everyone for your responses. I figured it was worth a shot
if anyone had a radical idea.

Alan Nishioka

Hi Alan,

Surprisingly, it may be it works 'better' than the ordinary solution. This
is because the interposer's power planes can be set up differently from the
main PCB's power planes. Whereas the main PCB's power planes are probably a
compromise for the whole circuit, the interposer's planes can be designed to
be optimal for the FPGA. A more expensive stackup can be used as the
interposers are small. Bypass caps can be mounted on the interposer.

Here's a link which explains better than I can.
http://www.samtec.com/sudden_service/current_literature/powerposer.asp

Anyway, good luck with it all, I've been in similar situations myself, and
the usual solution is a redesign. :-(

Best, Syms.

 

[MH]

"Alan Nishioka" <alan@nishioka.com> wrote in message news:xQqPj.5333$iK6.4113@nlpi069.nbdc.sbc.com...

Xilinx is canceling the Virtex-E XCV1000E-FG860.

We are currently shipping a product that uses 13 of these chips on 4 different boards.

Does anyone have any ideas on how to deal with this?

One possibility is to rev the boards to use the XCV1000E-FG900, making minimal changes to the boards around the fpga.

Complete re-design of the boards for this old system is out of the question. Stockpiling a bunch of parts won't work because
we don't know what future quantities will be and the parts are very expensive.

Alan Nishioka
alan@nishioka.com

Hey Alan,

I'll do a V5 replacement design if the price is right - although it's
been a few years since I worked on that particular project....

Cheers

Mike H

(Didn't see you at NAB?)

 

[MH]

"Alan Nishioka" <alan@nishioka.com> wrote in message news:xQqPj.5333$iK6.4113@nlpi069.nbdc.sbc.com...

Xilinx is canceling the Virtex-E XCV1000E-FG860.

We are currently shipping a product that uses 13 of these chips on 4 different boards.

Does anyone have any ideas on how to deal with this?

One possibility is to rev the boards to use the XCV1000E-FG900, making minimal changes to the boards around the fpga.

Complete re-design of the boards for this old system is out of the question. Stockpiling a bunch of parts won't work because
we don't know what future quantities will be and the parts are very expensive.

Alan Nishioka
alan@nishioka.com

Hey Alan,

I'll do a V5 replacement design if the price is right - although it's
been a few years since I worked on that particular project....

Cheers

Mike H

(Didn't see you at NAB?)

 

[MM]

<mspiegels@gmail.com> wrote in message
news:158c50e1-7947-4c77-80a8-b887eab3e267@z72g2000hsb.googlegroups.com...

Heey Austin and Mikhail,

Thanks for the replies, it's still a bit difficult for me to make sens
of it all because i have to learn more about these "buffers" (IBUFG
and BUFG) but some more research on the internet will probably do the
trick. It's clear now that these DCM's are internal and no physical
pins are involved. A little fight with ISE to get the DCM IP-block
work will be needed
Offcourse if anyone has made a little program with a DCM involved, any
code of how it's implemented is welcome.
Once again: thanks!

It is all in the documentation for the tools and for the chips. Internet
research is not required. DCM IP block is very easy to get to work. However,
perhaps before going there you should acquire some more basic skills of
working with the tools. Learn how to do a LED flasher or something like
that... Then add a DCM in it...


/Mikhail

 

[MM]

<mspiegels@gmail.com> wrote in message
news:158c50e1-7947-4c77-80a8-b887eab3e267@z72g2000hsb.googlegroups.com...

Heey Austin and Mikhail,

Thanks for the replies, it's still a bit difficult for me to make sens
of it all because i have to learn more about these "buffers" (IBUFG
and BUFG) but some more research on the internet will probably do the
trick. It's clear now that these DCM's are internal and no physical
pins are involved. A little fight with ISE to get the DCM IP-block
work will be needed
Offcourse if anyone has made a little program with a DCM involved, any
code of how it's implemented is welcome.
Once again: thanks!

It is all in the documentation for the tools and for the chips. Internet
research is not required. DCM IP block is very easy to get to work. However,
perhaps before going there you should acquire some more basic skills of
working with the tools. Learn how to do a LED flasher or something like
that... Then add a DCM in it...


/Mikhail

 

[Uwe Bonnes]

dalai lamah <antonio12358@hotmail.com> wrote:

Un bel giorno austin digitň:

With the small volume, re-design of the pcb is just not going to be
worth the money spent (you will never recover it)

It doesn't look so expensive. Of course it depends on PCB complexity, but
let's say 1000 $ for remastering and 1000 $ for the new PCB masks. In a
product where a single piece mounts 13 of those parts (AVnet sells 100
pieces of them at 963$ each!) it's quite easy to write off a 2000 $
investment.

But then the manifacturer needs to cope with two bitfiles..
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Robert Lacoste]

"Julio Espada" <newsnet@jmo.biz> a écrit dans le message de news:
481125b4$0$14073$a729d347@news.telepac.pt...

Hi!

I'm looking for the Atmel ATF750C library for Proteus but I'm unable to
find it on both Atmel & Labcenter sites. Does anyone know where can I find
this ? Or perhaps, any other application that can simulate the ATF750C ?

Have you asked Labcenter directly through their web forum ? They are usually
very quick in providing good answers... and even to model a couple of new
components free of charge for registered customers...

If not then another way may be just to use a generic PAL simulator, as this
chip seems to be a kind of 22V10. Old but good tools like PALASM ?

Yours,
Robert
www.alciom.com

 

[Symon]

krunal wrote:

hi....I want to implement Sigma Delta ADC in Spartan 3E starter
kit....i have implemented it as xilinx's xapp-155.....in ise it works
well for 8 bit....but give problem for 16 bit.....When i open it in
sysgen it now work.......actually in program the dac.v is
included......i dont know how to open that include file in
sysgen....please help........if any one have verilog or vhdl code for
that please send me........and i want to interface the exeternal ADC
also.....so please help me......

..-. - ..-. --
..... - ....
.... -.-- -- ...

 

[Symon]

krunal wrote:

hi....I want to implement Sigma Delta ADC in Spartan 3E starter
kit....i have implemented it as xilinx's xapp-155.....in ise it works
well for 8 bit....but give problem for 16 bit.....When i open it in
sysgen it now work.......actually in program the dac.v is
included......i dont know how to open that include file in
sysgen....please help........if any one have verilog or vhdl code for
that please send me........and i want to interface the exeternal ADC
also.....so please help me......

..-. - ..-. --
..... - ....
.... -.-- -- ...

 

[Symon]

\ /
- -
/ \


\ /
- - -
/

\ \ / \|
- -
/| |

/ | \ /
- - - - - - -
\ | / /| / |


?

 

[Symon]

Thorsten Kiefer wrote:

Hi,

i get the following error messages :
HDLParsers:800 - "/home/thorsten/work/xilinx/vgatest1/vga_test.vhd"
Line 66. Type of mousex_reg is incompatible with type of MXINIT.
ERROR:HDLParsers:800 -
"/home/thorsten/work/xilinx/vgatest1/vga_test.vhd" Line 67. Type of
mousey_reg is incompatible with type of MYINIT.

using the unsigned() conversion function doesnt work either.

Best Regards
Thorsten

Hi Thorsten,
Try http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf
Also, you might be better asking this sort of thing on comp.lang.vhdl .

HTH., Syms.

 

[Symon]

austin wrote:

Syms,

Morose vode?

Austin

I was inspired by this:-
http://www.youtube.com/watch?v=q9v3C08oLqA

Sorry!
Syms.

 

[Symon]

austin wrote:

Syms,

Thanks! Wonderful.

In all seriousness, I would suggest we treat the newbies with a little
more patience. It isn't easy starting out in this field. I know
these folks will not become your customers, but they might someday be
mine.

Austin

Austin,

I gratefully accept the rebuke.

In mitigation for my actions, I worry this newsgroup could turn into
something as useless as sci.whatever.idiots which I occasionally get
subjected to because of thoughtless cross postings.

I've personally learnt a lot through this newsgroup over the years, from
some very smart folks. I've learnt from you too. (Kidding!) It would be a
terrible shame if smart folks stopped contributing because of people who
can't even take the courtesy to post coherently.

So, try this link, but, at the end, substitute 'comp.arch.fpga' for 'New
Scientist' and 'FPGAs' for 'science'!
http://www.youtube.com/watch?v=-_2xGIwQfik

Cheers, Syms.

p.s. Are you any good on an Aldiss Lamp?

 

[Symon]

austin wrote:

swissi,

I have no idea what you are trying to tell me.

Austin

Hey Austin,
You remember a day or two ago, in all seriousnes, you said I need to treat
your future customers with a little patience? Let me know when I can be rude
to this one! To be honest, I don't think they're a 'keeper'.
Thanks, Syms.

 

[Gavin Scott]

austin <austin@xilinx.com> wrote:

Are you just trying to check that we are using AES256?

I think it's this that he's trying to do.

G.

 

[Symon]

freeagent.20.oracle@xoxy.net wrote:

I would like to automatically embed the Xilinx compile (synthesize)
time into my FPGA. I have a script file that can put the time and date
into my Verilog code.


Bob

Hi Bob,
You could use data2mem to put the time into a BRAM after the compile is
complete. Dunno if that helps you?
Cheers, Syms.