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 117525

Article: 117525
Subject: Re: Implementing a communication protocol for data transfer over TCP on an FPGA
From: nmm1@cus.cam.ac.uk (Nick Maclaren)
Date: 3 Apr 2007 14:12:48 GMT
Links: << >>  << T >>  << A >>

In article <461257ca$0$6411$9b4e6d93@newsspool2.arcor-online.net>,
"Andre Renee" <traubenuss@arcor.de> writes:
|>
|> Then I thought about Telnet but I am afraid I am not familiar enough with it 
|> to estimate if it allows the transfer of files. Is there any simple solution 
|> to transmit files from a PC to the FPGA board with a plain application 
|> protocoll layer?

FTP or even TFTP.  You can do it a lot more simply, but it sounds as
if you aren't the sort of person who is happy designing a one-off
protocol.  WITH FTP, you need implement only one form of binary.


Regards,
Nick Maclaren.

Article: 117526
Subject: Re: Implementing a communication protocol for data transfer over TCP on an FPGA
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Tue, 3 Apr 2007 15:13:29 +0100
Links: << >>  << T >>  << A >>

"Andre Renee" <traubenuss@arcor.de> wrote in message 
news:461257ca$0$6411$9b4e6d93@newsspool2.arcor-online.net...
>  I implemented the TCP/IP stack fully in hardware in VHDL and it works.

Man!

> Is there any simple solution to transmit files from a PC to the FPGA board 
> with a plain application protocoll layer?

Personally, I would look at GNU Netcat(http://netcat.sourceforge.net/) for 
very simple file transfer over TCP/UDP. You might also try TFTP (yuk).

Good luck,

    -Ben-



Article: 117527
Subject: Re: Implementing a communication protocol for data transfer over
From: Tauno Voipio <tauno.voipio@INVALIDiki.fi>
Date: Tue, 03 Apr 2007 14:29:16 GMT
Links: << >>  << T >>  << A >>
Andre Renee wrote:
> Hi,
> 
> I am currently working on a project where I have to transmit data from a PC 
> to an FPGA board via Ethernet. For that purpose I use the HTG-V4PCIe 
> evaluation board, which is a Xilinx Virtex-4 PCI Express Development Board 
> from HighTech Global (http://www.hitechglobal.com/boards/v4pcie.htm). It 
> features the Marvell Alaska 88E1111 Gigabit-Ethernet PHY which I use in 
> combination with the Virtex-4 built-in MAC interface. I implemented the 
> TCP/IP stack fully in hardware in VHDL and it works. Fine! :-)
> 
> Now I have some serious problems with the data transmission and maybe 
> someone could point me to the right direction.
> 
> For transmitting the data from the PC to the board (in the form of files) I 
> need some sort of application protocoll layer, I guess. First I thought 
> about HTTP which is in my opinion a bit overkill, because all I want to do 
> is transmit files FROM the PC TO the FPGA. I may run a HTTP server on the 
> FPGA's Microblaze but I have the impression that would not satisfy my need 
> of just transmitting data files.
> Then I thought about Telnet but I am afraid I am not familiar enough with it 
> to estimate if it allows the transfer of files. Is there any simple solution 
> to transmit files from a PC to the FPGA board with a plain application 
> protocoll layer?
> 
> Any help is highly appreciated.

The simple way is TFTP. It uses UDP as the transport layer,
so even TCP is not needed. However, there's practically no
security, and the protocol is a simple send-and-wait-for-
ack protocol. For local links, it's simple and works.

TFTP was created to boot diskless workstations, and for
similar tasks it's OK.

For more general file transfer, FTP is probably the correct
thing, although it's much more tedious to implement than TFTP.

The primary reference for TFTP is
<http://www.faqs.org/rfcs/rfc1350.html>.

-- 

Tauno Voipio
tauno voipio (at) iki fi


Article: 117528
Subject: Re: Help with a face recognition system
From: "Patrick Dubois" <prdubois@gmail.com>
Date: 3 Apr 2007 08:21:24 -0700
Links: << >>  << T >>  << A >>
On Apr 3, 8:59 am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote:
> PS3 has only 1 power processor and _6_ SPE cores.
>  http://en.wikipedia.org/wiki/PlayStation_3#Central_processing_unit

Nope, 1 central PPC core and 8 Synergistic Processor Unit:
http://www.research.ibm.com/cell/heterogeneousCMP.html




Article: 117529
Subject: Re: Implementing a communication protocol for data transfer over TCP on an FPGA
From: "Andre Renee" <traubenuss@arcor.de>
Date: Tue, 3 Apr 2007 17:22:03 +0200
Links: << >>  << T >>  << A >>
Hi Nick,

thanks for your quick reply. The problem is: with my TCP/IP implementation I 
have only one port available. As far as I know with FTP I need at least 
two...!? 



Article: 117530
Subject: Re: Implementing a communication protocol for data transfer over TCP on an FPGA
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 3 Apr 2007 08:42:13 -0700
Links: << >>  << T >>  << A >>
On Apr 3, 9:12 am, n...@cus.cam.ac.uk (Nick Maclaren) wrote:
> In article <461257ca$0$6411$9b4e6...@newsspool2.arcor-online.net>,"Andre Renee" <trauben...@arcor.de> writes:
>
> |>
> |> Then I thought about Telnet but I am afraid I am not familiar enough with it
> |> to estimate if it allows the transfer of files. Is there any simple solution
> |> to transmit files from a PC to the FPGA board with a plain application
> |> protocoll layer?
>
> FTP or even TFTP.  You can do it a lot more simply, but it sounds as
> if you aren't the sort of person who is happy designing a one-off
> protocol.  WITH FTP, you need implement only one form of binary.
>
> Regards,
> Nick Maclaren.

If you have to write on the PC side as well, simple TCP socket
communication should be simple.
If not, just implement a simple TFTP server with the bare minimum in
the FPGA, so you can connect from any computer with "tftp" command.

Regards,
Zoltan


Article: 117531
Subject: RFC: VHDL testbench enhancements
From: Jim Lewis <jim@synthworks.com>
Date: Tue, 03 Apr 2007 09:10:58 -0700
Links: << >>  << T >>  << A >>
Hi,
Let me try this again.

The VHDL standards community has been considering whether
to enhance VHDL to add advanced testbench features.

If you are a VHDL user,
   Do you want these features added to VHDL?
   Would you rather adopt a verification language that
   already supports these (SystemVerilog, SystemC, E, Vera).

I think VHDL needs these features to stay competitive.

The current plan in the VHDL working group is to make
these features similar to other verification languages
while at the same time keeping the nature of VHDL.

We need your to voice your support.  You can post here,
send your reply to me (let me know if I can use either
your name and/or company name when I tally the results
for the Accellera VHDL TSC), or join the Accellera VHDL
TSC (which you can do as a non-Accellera member by
registering) and post your reply there.

More on the politics of the situation are below.

Thanks,
Jim Lewis
VHDL Evangelist
SynthWorks VHDL Training



P.S.
One of the simulator vendors has indicated that will
only implement new features if the user community
demands them.  Business wise, this makes sense - you
don't build something unless someone will buy it.

If you fail to voice your support, they may be able to
successfully block these proposals from going forward.

If we let this opportunity to add these features to the
standard pass, I do not think we will have to opportunity
to add them later - hence you will be stuck with using
some other language for advanced verification features.

This work is work in progress and below is the current status.
Keep in mind too that your interest/support of this work will
help raise the focus and inspiration of those doing the work.

   Classes / OO:
     Classes are useful for creating verification data structures,
     transaction communication, and grouping for transaction based
     randomization (building relationships between separate data
     items).  Many of the data structures (such as scoreboards,
     memories, and linked structures) can already be created, however,
     classes give you the ability to hide all pointer manipulations.
     For example, using a memory would require a declaration with
     initialization of the memory data structure, then MemWrite and
     MemRead would allow a user to store and retrieve items from the
     data structure.  Pointers and allocation of the sparse data
     structure are handled by MemWrite and MemRead and the
     user would not need to be aware of it.
     Status:
     Peter Ashenden submitted a class proposal last year and
     provided updates to it this year at DVCon.  Currently
     he plans on finishing an updated draft soon.

   Randomization:
     Randomization is useful for designs that have numerous configurable
     features.  Testing features individually in an isolated manner is
     typically straightforward. However, testing how these features
     interact can be a large verification space  one that may not be able
     to be simulated completely. It is also may be difficult to predict
     all of the corner cases.  Randomization has been used to sequence a
     test in a non-deterministic way to get reasonably good coverage of
     this verification space.
     While I do not share the thought that randomization should be
     adapted to work for all verification problems, I do believe it
     to be a valuable technique for some problems.

     I wrote a draft of the randomization proposal and it is ready
     for review.

   Functional Coverage:
     Tool/structural coverage can tell you that you did a FIFO
     read or that the the FIFO went empty, but it can't tell
     you that you did a read while the FIFO was empty.

     Functional coverage constructs allow you to track this.
     Some functional coverage capability will come from assertions
     (since PSL has been integrated into VHDL).  Additional constructs
     will be added to allow data binning (coverage groups) and
     correlation between different coverage items (cross coverage).

     I have started working on this - anyone else who is interested
     is welcome to contribute as much as they would like.


With a focused effort, like the one to finish the Accellera 3.0
draft of the standard, I think we can be done with these by
September.

Although some have expressed doubt, it is clear that vendors
will do what their user community asks them to do - otherwise,
someone else will and, as a result, will earn your business.


Jim


Article: 117532
Subject: Re: RFC: Enhancing VHDL for OO, Randomization, Functional Coverage
From: "Torsten Landschoff" <t.landschoff@gmx.de>
Date: 3 Apr 2007 09:37:08 -0700
Links: << >>  << T >>  << A >>
Hi Jim,

On 29 Mrz., 23:51, Jim Lewis <j...@synthworks.com> wrote:
> Currently the Accellera VHDL TSC is working on enhancements
> to add classes/OO, Randomization constructs, and Functional
> Coverage with a goal of giving VHDL the same verification
> capability as SystemVerilog or E.
>
> One of the VHDL simulation vendors has indicated that they
> only want to implement new features if the user community
> wants these features.

I just started with VHDL two months ago and I have to say that I find
it frustrating that I keep running into unimplemented parts of the
VHDL standard. That's with the Xilinx toolchain and I read a lot of
that already that I can confirm. A few days before I tried to model a
ADC wrt. the timing constraints and had to notice that the Xilinx ISE
Simulator (non ModelSim :() does not support the stable attribute.

Okay, enough of the rant, what I wanted to say is that I'd expect the
implementations to conform to the standard.

>    Classes / OO:
>      Peter Ashenden submitted a class proposal last year and
>      provided updates to it this year at DVCon.  Currently
>      he plans on finishing an updated draft soon.

I'd really like to see that proposal. Coming from software development
it really seems logical to apply OO to HDLs.

>    Randomization:
>      I just submitted the first draft of the randomization proposal.

Also very interesting, we will need pseudo random data for our project
as well. Some kind of LFSR will be good enough but having it directly
supported would be nice, also for synthesis. I can dream, right :)

> You can post here, send your reply to me (let me know if I can use
> either your name and/or company name when I tally the results
> for the Accellera VHDL TSC), or join the Accellera VHDL TSC
> (which you can do as a non-Accellera member by registering)
> and post your reply there.

While I am just starting with VHDL, I'd like to contribute. In fact, I
became member of IEEE-SA just for that. I figured following that
discussion would also be the best way to learn VHDL, just as my
involvement with Debian GNU/Linux as a developer was a real boost for
my Linux know how. However, I don't think my company is interested in
spending money and developer time on it so I could only use my spare
time for it.

Greetings, Torsten


Article: 117533
Subject: Re: RFC: Enhancing VHDL for OO, Randomization, Functional Coverage
From: "Torsten Landschoff" <t.landschoff@gmx.de>
Date: 3 Apr 2007 09:45:19 -0700
Links: << >>  << T >>  << A >>
Hi Jim,

I just noticed that I did not really answer your questions, therefore
I'll try again :-)

On 29 Mrz., 23:51, Jim Lewis <j...@synthworks.com> wrote:

> The questions come down to:
>    Do you want these features added to VHDL?
>    Do you want to VHDL to be capable of handling all of your
>    testbench needs?
> [...]
>
>    Classes / OO:
>      Peter Ashenden submitted a class proposal last year and
>      provided updates to it this year at DVCon.  Currently
>      he plans on finishing an updated draft soon.

Yes, classes/OO would be very welcome.

>    Randomization:
>      I just submitted the first draft of the randomization proposal.

Same for randomization.

>    Functional Coverage:
>      I have started working on this - anyone else who is interested
>      is welcome to contribute as much as they would like.

Everybody should want coverage tests as it is important for
correctness. I am not sure though how this will require language
changes?

And of course I'd like to use only VHDL for our test benches. Tcl and
VHDL kind of works but is not as portable and standardized.

Greetings, Torsten

PS: I am working for nAmbition GmbH but any opinions given above are
my own. Feel free to use my name.


Article: 117534
Subject: Boot PowerPC on VirtexIIPro
From: "Pablo" <pbantunez@gmail.com>
Date: 3 Apr 2007 10:25:53 -0700
Links: << >>  << T >>  << A >>
Well I have a strange problem. I have a VirtexIIPro30 on a Sundance
target. I use XPS 8.2.02 to create a design with a 16KB of
plb_bram_if_cntlr, and GPIO LED with bandwith 2. I add a Test_App
Peripheral for testing leds but it seems like powerpc doesn't boot
(work). I don't see the leds on and I have probed the design in a
Microblaze on a Spartan. The test app is fine.

PD: I have not JTAG for debugging. I have only an application to
download "bitstream" and it is ok because I have download vhdl models
on virtex.

Does I have to init anything or use OCM??

Thanks


Article: 117535
Subject: Re: Dynamic Reconfig
From: Neil Steiner <neil.steiner@vt.edu>
Date: Tue, 03 Apr 2007 13:55:41 -0400
Links: << >>  << T >>  << A >>
[With apologies for re-ordering your questions:]

> ... if you guys could give me some suggestions on a trivial example
> for me to test and see that partial dynamic reconfig actually works
> using the ICAP.

If you're wondering whether it actually works, yes it does, and very nicely.

> ... I would assume that the patial bitstreams would be generated
> using the FPGA editor from Xilinx.

The bitstreams would in fact be generated by bitgen, though you could 
use HDL source or EDIF netlists or FPGA Editor to generate the .ncd that 
bitgen would use.  You can pass "-r <original.bit>" to bitgen to ask it 
to generate a bitstream that only includes frames that differ between 
your original bitstream and your new bitstream.  That's how partial 
bitstreams are created.

Because you're interested in active reconfiguration (i.e. 
reconfiguration of the FPGA while it's running), you also have to tell 
bitgen not to shut down the device, by passing "-g ActiveReconfig:Yes" 
to bitgen.  Otherwise the very first thing the bitstream will do is stop 
the FPGA, and since you're reconfiguring the device from the inside, 
you'll have aborted the reconfiguration, with nothing to re-awaken the 
device.

There are a few other considerations, such as not corrupting frames that 
contain LUT RAMs (including SRL16s) or BRAMs, but you probably don't 
need to worry about that quite yet.

> Now assuming I want to have a set of bit streams loaded on to the
> Internal memory buffer of the microblaze,How do I do that i.e how do
> I store the bit streams on the microblaze(internal memory).I am using
> an ML310 board.

I'm not sure exactly what you're asking.  When you speak of the 
"internal memory buffer of the microblaze", are you thinking of BRAM 
inside the FPGA, as opposed to external memory on the ML310 board?  (And 
do keep in mind that the XC2VP30 on your ML310 only has about 306 KB of 
BRAM.)

What exactly are you running?  Is this uClinux on a MicroBlaze on the 
ML310?  (I'm using regular Linux on PowerPC on the XUP V2Pro, so I can't 
directly provide you with an example.)

And what are you trying to do with this?  Or are you simply trying to 
verify to your own satisfaction that the concept does work?

As for talking to the ICAP, you can use John's ICAP driver if you're 
running uClinux.  Or you can use 
http://www.ccm.ece.vt.edu/~nsteiner/icap/ if you're running regular 
Linux (at least for kernel 2.4.x).  Or you can always talk directly to 
the Xilinx xhwicap driver, instead of going through a Linux/uClinux 
driver.  Documentation for the xhwicap driver is available with the EDK, 
and the source for John's driver or for my driver may help you better 
understand how to talk to the xhwicap driver.

If you start making progress with this, then consider the following 
correction to the xhwicap driver: 
http://groups.google.bs/group/comp.arch.fpga/browse_thread/thread/02e00d4ec0ef783e 
  This correction will spare you some grief if you're trying to write 
multiple frames without aligning them on boundaries.  Probably something 
that you don't need to worry about yet though.

Article: 117536
Subject: Re: Help with a face recognition system
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Tue, 03 Apr 2007 18:00:53 GMT
Links: << >>  << T >>  << A >>
On a sunny day (3 Apr 2007 08:21:24 -0700) it happened "Patrick Dubois"
<prdubois@gmail.com> wrote in
<1175613684.443163.290410@d57g2000hsg.googlegroups.com>:

>On Apr 3, 8:59 am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote:
>> PS3 has only 1 power processor and _6_ SPE cores.
>>  http://en.wikipedia.org/wiki/PlayStation_3#Central_processing_unit
>
>Nope, 1 central PPC core and 8 Synergistic Processor Unit:
>http://www.research.ibm.com/cell/heterogeneousCMP.html

Nope, in the PS3 only 6 are available.

Article: 117537
Subject: Re: RFC: VHDL testbench enhancements
From: "Andy" <jonesandy@comcast.net>
Date: 3 Apr 2007 11:16:08 -0700
Links: << >>  << T >>  << A >>
On Apr 3, 11:10 am, Jim Lewis <j...@synthworks.com> wrote:
> Hi,
> Let me try this again.
>
> The VHDL standards community has been considering whether
> to enhance VHDL to add advanced testbench features.
>
> If you are a VHDL user,
>    Do you want these features added to VHDL?
>    Would you rather adopt a verification language that
>    already supports these (SystemVerilog, SystemC, E, Vera).
>
> I think VHDL needs these features to stay competitive.
>
> The current plan in the VHDL working group is to make
> these features similar to other verification languages
> while at the same time keeping the nature of VHDL.
>
> We need your to voice your support.  You can post here,
> send your reply to me (let me know if I can use either
> your name and/or company name when I tally the results
> for the Accellera VHDL TSC), or join the Accellera VHDL
> TSC (which you can do as a non-Accellera member by
> registering) and post your reply there.
>
> More on the politics of the situation are below.
>
> Thanks,
> Jim Lewis
> VHDL Evangelist
> SynthWorks VHDL Training
>
> P.S.
> One of the simulator vendors has indicated that will
> only implement new features if the user community
> demands them.  Business wise, this makes sense - you
> don't build something unless someone will buy it.
>
> If you fail to voice your support, they may be able to
> successfully block these proposals from going forward.
>
> If we let this opportunity to add these features to the
> standard pass, I do not think we will have to opportunity
> to add them later - hence you will be stuck with using
> some other language for advanced verification features.
>
> This work is work in progress and below is the current status.
> Keep in mind too that your interest/support of this work will
> help raise the focus and inspiration of those doing the work.
>
>    Classes / OO:
>      Classes are useful for creating verification data structures,
>      transaction communication, and grouping for transaction based
>      randomization (building relationships between separate data
>      items).  Many of the data structures (such as scoreboards,
>      memories, and linked structures) can already be created, however,
>      classes give you the ability to hide all pointer manipulations.
>      For example, using a memory would require a declaration with
>      initialization of the memory data structure, then MemWrite and
>      MemRead would allow a user to store and retrieve items from the
>      data structure.  Pointers and allocation of the sparse data
>      structure are handled by MemWrite and MemRead and the
>      user would not need to be aware of it.
>      Status:
>      Peter Ashenden submitted a class proposal last year and
>      provided updates to it this year at DVCon.  Currently
>      he plans on finishing an updated draft soon.
>
>    Randomization:
>      Randomization is useful for designs that have numerous configurable
>      features.  Testing features individually in an isolated manner is
>      typically straightforward. However, testing how these features
>      interact can be a large verification space - one that may not be able
>      to be simulated completely. It is also may be difficult to predict
>      all of the corner cases.  Randomization has been used to sequence a
>      test in a non-deterministic way to get reasonably good coverage of
>      this verification space.
>      While I do not share the thought that randomization should be
>      adapted to work for all verification problems, I do believe it
>      to be a valuable technique for some problems.
>
>      I wrote a draft of the randomization proposal and it is ready
>      for review.
>
>    Functional Coverage:
>      Tool/structural coverage can tell you that you did a FIFO
>      read or that the the FIFO went empty, but it can't tell
>      you that you did a read while the FIFO was empty.
>
>      Functional coverage constructs allow you to track this.
>      Some functional coverage capability will come from assertions
>      (since PSL has been integrated into VHDL).  Additional constructs
>      will be added to allow data binning (coverage groups) and
>      correlation between different coverage items (cross coverage).
>
>      I have started working on this - anyone else who is interested
>      is welcome to contribute as much as they would like.
>
> With a focused effort, like the one to finish the Accellera 3.0
> draft of the standard, I think we can be done with these by
> September.
>
> Although some have expressed doubt, it is clear that vendors
> will do what their user community asks them to do - otherwise,
> someone else will and, as a result, will earn your business.
>
> Jim

Yes! I whole-heartedly support expanding the "testbench" features of
VHDL. The main problem with using separate languages to create the
testbench are two-fold. 1) multi-language simulators are more
expensive, and 2) there are always some gotcha's at the interface when
it comes to connecting the testbench to the UUT, especially if you use
other than SL or SLV port types for your UUT.

That being said, I would caution against creating too much variance in
VHDL between what can be done in a simulation only environment, vs a
synthesis environment. OO principles come to mind. The eventual
application of OO to synthesis should be carefully considered when
developing the OO structure and syntax, even though it is now just for
simulation.

Also, there are plenty of areas in synthesizable vhdl that need work
too, like user definable modes for record ports, expanded integer
synthesis (boolean operator definition, expanded range), as well as
fixed point representations along the lines of ada.

Andy


Article: 117538
Subject: Re: RFC: VHDL testbench enhancements
From: Jim Lewis <jim@synthworks.com>
Date: Tue, 03 Apr 2007 11:25:08 -0700
Links: << >>  << T >>  << A >>
Andy,
Thanks for your post.  We are in the position where we need to
hear all users speak up (privately to me is ok), even when they
agree with what has already been stated.

> Yes! I whole-heartedly support expanding the "testbench" features of
> VHDL. The main problem with using separate languages to create the
> testbench are two-fold. 1) multi-language simulators are more
> expensive, and 2) there are always some gotcha's at the interface when
> it comes to connecting the testbench to the UUT, especially if you use
> other than SL or SLV port types for your UUT.
> 
> That being said, I would caution against creating too much variance in
> VHDL between what can be done in a simulation only environment, vs a
> synthesis environment. OO principles come to mind. The eventual
> application of OO to synthesis should be carefully considered when
> developing the OO structure and syntax, even though it is now just for
> simulation.
> 
> Also, there are plenty of areas in synthesizable vhdl that need work
> too, like user definable modes for record ports, expanded integer
> synthesis (boolean operator definition, expanded range), as well as
> fixed point representations along the lines of ada.

Record ports is high on my list too.  Have to finish the verification
features first.  The other items you mention also sound interesting.

Cheers,
Jim

Article: 117539
Subject: Re: FPGA with 5V and PLCC package
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 03 Apr 2007 14:14:51 -0500
Links: << >>  << T >>  << A >>


Herbert Kleebauer wrote:

>We use in a laboratory course still XILINX XC3000 FPGAs with
>Viewlogic's Workview design entry (DOS version) and XILINX
>XACT (also DOS). The problem is that we have to replace the 
>old PC's and that Viewlogic only supports a few graphics modes 
>and it is unlikely that it will run on new PC's. The last
>version of XILINX ISE software which supports XC3000 FPGA's
>isn't an alternative (and I'm not sure whether it will
>run on W2k/XP) because the system must be extremely easy to
>use so the students are able to design and implement a simple
>CPU in about 10 hours (including the time to learn how to use
>the schematic entry and simulation tool).
>
>Some questions:
>
>1. I have tried to find an actual FPGA with a package which can
>   be soldered with a non professional equipment, something like
>   a PLCC84 where you can get cheap sockets which can be used on
>
You can use Xilinx Spartan chips such as XCS10-xPC84 (x is the speed grade).
I don't remember how big the array goes in the PC84 package.  With a 
little more
soldering skill, there are flat pack Spartan chips, such as 144-pin.

You need to use Xilinx's ise 5.2 or earlier software to generate configs 
for these
older chips.  Despite Xilinx pulling all references to them off their 
web site,
the 5 V Spartans are still available.  They are a little harder to get 
in small quantity,
but if you need 50 or something, it would be no problem.

>   self made PCBs and if possible with a VCC of 5 V to easy interface
>   with external TTL logic. XILINX and ACTEL only offers packages with
>  
>
Jon


Article: 117540
Subject: Re: FPGA with 5V and PLCC package
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 03 Apr 2007 14:21:33 -0500
Links: << >>  << T >>  << A >>


Herbert Kleebauer wrote:

>The problem is not the money, but the time of the students.
>The system must be very easy to use so the students can built
>the simple CPU at gate level in 10 hours including the time to 
>learn the tools.
>
This is a fantasy!  You could probably design a 2-bit adder at the gate
level in 10 hours, starting from not knowing the package.  There is no
way a student could design a CPU at the gate level, unless it was maybe
a Turing machine (one-bit CPU), in 10 hours.  Even if they were fluent in
VHDL, every toolkit has its own dialect of what is accepted and what is
not.  Then, you have to learn the simulator, how to write test benches,
debug the board, the FPGA soldering, testing the FPGA config ON the
target board.....

I run Xilinx ise 5.1 and 5.2 on Windows 2000.  I'm still working in the
5 V world for a little while longer.

Jon


Article: 117541
Subject: Re: FPGA with 5V and PLCC package
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 03 Apr 2007 14:23:58 -0500
Links: << >>  << T >>  << A >>


Herbert Kleebauer wrote:

>msg wrote:
>  
>
>>Herbert Kleebauer wrote:
>>    
>>
> 
>  
>
>>>2. Was somebody able to run Viewlogic (DOS version) in a virtual
>>>   PC emulation.  The  problem is, the virtual PC must provide
>>>   the proper graphics mode, mouse type and support a physical
>>>   dongle on the virtual parallel port.
>>>      
>>>
> 
>  
>
>>Also, it would be an interesting experiment to try running
>>the software on a VMWare MSDOS VM (a no-cost experiment); please
>>report the results!
>>    
>>
>
>  
>
I run Xilinx ise 5.2 on Windows 2000 under VMware, using Linux as the host
OS.  Win 2K is MUCH more reliable under VMware than on real hardware.
It stays up for months at a time.  I program EPROMS and download to CPLDs
through the JTAG on the parallel Cable III pod.

Jon


Article: 117542
Subject: Re: FPGA with 5V and PLCC package
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 03 Apr 2007 14:29:07 -0500
Links: << >>  << T >>  << A >>


cs_posting@hotmail.com wrote:

>But the fact of the matter is that there is hidden technology at all
>levels of the system.  As has been pointed out, the tools don't
>implement the actual gates you've drawn, they implement a logical
>equivelent.  And there's also sorts of hidden semi-proprietary stuff
>on the FPGA die.  You may find this easier to ignore with an older
>part, but it's still true.  Unless you go back to very raw TTL type
>chips (or maybe even earlier), what your students will be designing
>with is a black box abstraction that _does not really match_ its
>logical symbol representation except in explicit ways the data sheet
>says it does.
>
>  
>
The abstraction of the logic doesn't matter in the sense of a truth 
table (as long
as it is complete).  The result will match the truth table for sure. 
 But, the actual
logic pathways will not bear any resemblence to the schematics, and so 
the timing
will be radically different than what is drawn.  Of course, with good 
logic design,
it will still meet the design spec, but with crummy design planning, it 
sure won't.

Jon


Article: 117543
Subject: Re: Config PROM for Spartan II
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Tue, 03 Apr 2007 14:41:22 -0500
Links: << >>  << T >>  << A >>


Markus Knauss wrote:

> Hi all,
>
> at the moment, we are using AT17LV010 configuration devices for a 
> spartan 2S100.
> I have to look for a different solution which is not so expensive.
>
> The Xilinx XC17V01 is OTP and more expensive than the AT17LV010.
>
> Does someone know a different prom (OTP, EEPROM, Flash)?

SST makes a series of VERY cheap serial flash memories.  I figured out 
how to
create the command bit stream that it needs to command a read starting 
from addr
zero function, using just 2 SSI CMOS chips in SSOP packages, so the 
interface is
under $1, and the SST chip is well under $2 in small quantities.  I had 
to make my
own programmer, and a little C program to read the .MCS file and program the
device.  I haven't actually produced a product using this setup yet, but 
I did build
a prototype board for Spartan 2E and verify that it could do the FPGA 
configure.
I did this for the 2S50E part, but SST has up to 4 mbit chips, I think, 
that should
handle the 2S100.

Jon


Article: 117544
Subject: Looking for Memory Recommendation for Spartan 3E 1200
From: Matthias Einwag <matthias.einwag@web.de>
Date: Tue, 03 Apr 2007 23:03:29 +0200
Links: << >>  << T >>  << A >>
Hi everyone,

I'm working on a Board for Bus Interfacing and some Audio Processing, 
which will use Spartan 3E 1200 and the Microblaze.
Now I'm not sure what kind of memory I should use. Size ist not too 
important for me. 8Mbytes would be ok, but more is always better. But 
the speed should be high enough to get the Microblaze run at a decent 
speed and to allow permanent storing auf 4 stereo audio streams.
Most important is, that the layout and memory interface should run 
stable and from the beginning. There's not much time for error 
investigations and redesigns.

Spartan 3E Starter Kit uses a 16bit Wide DDR SDRAM Memory. But I read 
here and in some other boards, that people have much trouble with this 
one. Is this because Spartan 3E and the given IP Cores have always 
Trouble with DDR, or because of the missing clock feedback path on the 
board?

Another option would be normal SDRAM Memory. I think this should give 
less trouble. But here I'm wondering that Xilinx doesn't mention the 
Spartan 3E in the Device Family Support List of the OPB SDRAM Controller 
and the MultiChannel OPB SDRAM Controller. Only Spartan 3 and 3A are 
supported according to the Links on this page: 
http://www.xilinx.com/ise/embedded/edk_ip.htm
In fact the Spartan 3E is only listed in the support list for the OPB 
DDR SDRAM Controller. Are there mistakes in this list, or is spartan 3e 
really not supported by most memory controllers?

Greetings
Matthias

Article: 117545
Subject: Re: RFC: VHDL testbench enhancements
From: "Amal" <akhailtash@gmail.com>
Date: 3 Apr 2007 14:22:33 -0700
Links: << >>  << T >>  << A >>
On Apr 3, 2:25 pm, Jim Lewis <j...@synthworks.com> wrote:
> Andy,
> Thanks for your post.  We are in the position where we need to
> hear all users speak up (privately to me is ok), even when they
> agree with what has already been stated.
>
>
>
> > Yes! I whole-heartedly support expanding the "testbench" features of
> > VHDL. The main problem with using separate languages to create the
> > testbench are two-fold. 1) multi-language simulators are more
> > expensive, and 2) there are always some gotcha's at the interface when
> > it comes to connecting the testbench to the UUT, especially if you use
> > other than SL or SLV port types for your UUT.
>
> > That being said, I would caution against creating too much variance in
> > VHDL between what can be done in a simulation only environment, vs a
> > synthesis environment. OO principles come to mind. The eventual
> > application of OO to synthesis should be carefully considered when
> > developing the OO structure and syntax, even though it is now just for
> > simulation.
>
> > Also, there are plenty of areas in synthesizable vhdl that need work
> > too, like user definable modes for record ports, expanded integer
> > synthesis (boolean operator definition, expanded range), as well as
> > fixed point representations along the lines of ada.
>
> Record ports is high on my list too.  Have to finish the verification
> features first.  The other items you mention also sound interesting.
>
> Cheers,
> Jim

These new features are greatly needed and appreciated.
-- Amal


Article: 117546
Subject: Re: Looking for Memory Recommendation for Spartan 3E 1200
From: "John_H" <newsgroup@johnhandwork.com>
Date: Tue, 3 Apr 2007 15:07:23 -0700
Links: << >>  << T >>  << A >>
Consider the NOR Flash attached to the Spartan-3E starter kit's FPGA.


"Matthias Einwag" <matthias.einwag@web.de> wrote in message 
news:euufee$non$1@inn-newsserver.rz.tu-ilmenau.de...
> Hi everyone,
>
> I'm working on a Board for Bus Interfacing and some Audio Processing, 
> which will use Spartan 3E 1200 and the Microblaze.
> Now I'm not sure what kind of memory I should use. Size ist not too 
> important for me. 8Mbytes would be ok, but more is always better. But the 
> speed should be high enough to get the Microblaze run at a decent speed 
> and to allow permanent storing auf 4 stereo audio streams.
> Most important is, that the layout and memory interface should run stable 
> and from the beginning. There's not much time for error investigations and 
> redesigns.
>
> Spartan 3E Starter Kit uses a 16bit Wide DDR SDRAM Memory. But I read here 
> and in some other boards, that people have much trouble with this one. Is 
> this because Spartan 3E and the given IP Cores have always Trouble with 
> DDR, or because of the missing clock feedback path on the board?
>
> Another option would be normal SDRAM Memory. I think this should give less 
> trouble. But here I'm wondering that Xilinx doesn't mention the Spartan 3E 
> in the Device Family Support List of the OPB SDRAM Controller and the 
> MultiChannel OPB SDRAM Controller. Only Spartan 3 and 3A are supported 
> according to the Links on this page: 
> http://www.xilinx.com/ise/embedded/edk_ip.htm
> In fact the Spartan 3E is only listed in the support list for the OPB DDR 
> SDRAM Controller. Are there mistakes in this list, or is spartan 3e really 
> not supported by most memory controllers?
>
> Greetings
> Matthias 



Article: 117547
Subject: Re: FPGA with 5V and PLCC package
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 04 Apr 2007 11:44:26 +1200
Links: << >>  << T >>  << A >>
Jon Elson wrote:
> 
> 
> Herbert Kleebauer wrote:
> 
>> The problem is not the money, but the time of the students.
>> The system must be very easy to use so the students can built
>> the simple CPU at gate level in 10 hours including the time to learn 
>> the tools.
>>
> This is a fantasy!  You could probably design a 2-bit adder at the gate
> level in 10 hours, starting from not knowing the package.  There is no
> way a student could design a CPU at the gate level, unless it was maybe
> a Turing machine (one-bit CPU), in 10 hours.  Even if they were fluent in
> VHDL, every toolkit has its own dialect of what is accepted and what is
> not.  Then, you have to learn the simulator, how to write test benches,
> debug the board, the FPGA soldering, testing the FPGA config ON the
> target board.....

  I think Herbert was using the time, to illustrate the need for 
schematic flow, and built might not have meant physically assemble
a PCB, but probably includes bitstream and prom generate.

  You are both right - Herbert has a very short time or this section of 
the course, and yes, full VHDL Xilinx tool flows, will have too long a 
learning curve.

  His ideal is to continue to run the old Viewlogic system, and I
think some posts offered some hope.

  Failing that, I've suggested a Boolean Eqn entry scheme, that does
have a shorter learning curve, and is quick to run - and that is
close enough to the gate-level to see the AND.OR.Registers

  I have one ToolChain here, on a Flash drive, in under 10MB.

-jg




Article: 117548
Subject: Xilinx: WARNING:PhysDesignRules:372 (What the heck?)
From: Taylor Hutt <thutt151@comcast.net>
Date: 03 Apr 2007 16:45:05 -0700
Links: << >>  << T >>  << A >>


Hello again,

First, as a side note, Xilinx has so far gone out of their way to get
me the ability to file Webcases, and I'm grateful to everyone who
helped in that process, most notably, because he's where the ball
started rolling, Austin.  (And, I will file Webcases, but I've been
sick since last Wednesday)

However, I've run into a rather odd situation which I haven't yet been
able to figure out, and I'm not sure that this rises to the level of
actually filing a web case at this point.  Hopefully someone with more
experience with the Xilinx tools will be able to point me in the right
direction to figuring the situation out.

First, the background:

I'm creating an RS232 module which has send & receive.  I calculate
the basic ratio of  clock frequency for the RS232 like this:

   constant clock_ratio : integer := clock_rate / bps;

Where 'clock_rate' is 50,000,000 and 'bps' is 115200.

I have a generic library which will generate a clock of a particular
frequency, given a parameter 'n', which is the ratio of the FPGA clock
to the desired clock -- in other words, 'clock_ratio.

     signal    tx_clk   : std_logic;
     signal    rx_clk   : std_logic;

After the requisite parameter checking (i.e., ensure that 'bps > 0'), I
generate the transmit and receive clock signals like this

     rs232_tx_clk : entity clkdiv
       generic map (n  => clock_ratio)
       port map(clkin  => clk,
                reset  => '0',
                clkout => tx_clk);

     rs232_rx_clk : entity clkdiv
       generic map (n  => clock_ratio * 16)
       port map(clkin  => clk,
                reset  => '0',
                clkout => rx_clk);
     end generate;

When running, 'bitgen' produces the following warning:

    WARNING:PhysDesignRules:372 - Gated clock. Clock net
       rs232_port/tx_clk is sourced by a combinatorial pin. This is
       not good design practice. Use the CE pin to control the loading
       of data into the flip-flop.

'rs232_port/tx_clk' refers to the signal shown above, and it's the
clock signal for the RS232 TX block.

There is no warning for the 'rx_clk' signal, and if I change the 'n'
value of the instantiation of 'clkdiv' from 'clock_ratio' to
'clock_ratio * 16', as present for the 'rx_clk' generation, the
warning disappears.

My questions are these:

 -- Why does the warning appear?  As far as I can tell, there should
    be no combinatorial circuit -- but I'm a newbie, so I'm probably
    wrong.  (If the clkdiv source is required, I can provide it)

 -- Can anyone give me a clue why multiplying the ratio by 16 causes
    the warning to go away?

 -- What can I do, besides multiplying by 16, to get the error to go
    away?  (There is probably not enough information posted in this
    message to answer this question)

 -- Is there any way, short of looking at the ISE's RTL schematic, to
    see what the combinatorial circuit comprises (it's not obvious
    from the sources, as far as I can tell)?

Thanks for the help,
thutt    

Article: 117549
Subject: Re: X_OBUF and other error messages with ModelSim
From: "M. Hamed" <mhs000@gmail.com>
Date: 3 Apr 2007 16:55:29 -0700
Links: << >>  << T >>  << A >>
Problem solved. I contacted Xilinx, and they responded promptly that I
should upgrade my ModelSim to 6.2c that contains the new libraries.




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