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 43125

Article: 43125
Subject: Re: Architecture for high-level reconfigurable computing
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Tue, 14 May 2002 09:39:12 -0700
Links: << >>  << T >>  << A >>


"Keith R. Williams" wrote:

> Fuses?  The problem then moves to test, but it's been done.

Fuses are ugly:
1. take lots of current to blow (big drivers)
2. are not good for keeping a secret ( easily detected )
3. are inherently one-time-programmable, which does not sit well with the basic
concept of our FPGAs

Peter Alfke


Article: 43126
Subject: Re: Driving high speed external devices from an FPGA
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Tue, 14 May 2002 09:44:56 -0700
Links: << >>  << T >>  << A >>
If you use the DLL or DCM to eliminate the clock delay inside the FPGA,
and you register the data in the IOB, and you have a reasonable pc-board,
you will have no problem.
You might use clock forwarding (source-synchronous clocking), i.e. send
the clock with the data, but this is not necessary at your "low" speed.

Peter Alfke, Xilinx Applications
================================
Bert Wibble wrote:

> Hello all,
>
> Does anyone have any experience in driving external high speed devices
> from an
> FPGA, in particular a DAC ?
> To put some flesh around this, I am attempting to drive a 10bit DAC
> from an
> FPGA at 160MHz. The DAC and the FPGA share a common clock - but at
> this speed
> their exact phase allignment is not known.
> Internal to the FPGA (Xilinx), I am using a DLL/clock net to lock the
> internal
> clock to the external one.
> I am also happy with the idea that there will be a delay spread of the
> data through the FPGA IOB/pad combo.
>
> My question is - does anyone have any useful ideas on how I can
> guarantee to
> meet the setup and hold times of my DAC given the uncertainties of the
> clock
> delays ?
> There seems to be very little information around on this topic - is
> this
> another "black art" area ?
>
> Thanks in advance,
> Bert


Article: 43127
Subject: Anyody else get spam about "FPGA Video Seminar"?
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 14 May 2002 16:53:47 -0000
Links: << >>  << T >>  << A >>
I'll post a summary if anybody is interested.

Occasionally, I try to point out to marketing people that
they are damaging their reputation by spamming.  Occasionally
it works.  Often they "just don't get it".  They seem to be able
to rationalize that their stuff isn't spam.  I assume they think
it has to be porn or swindle to count as spam.

That's the sort of response I got when I asked them where they
got my email address.  (I'm pretty sure they harvested it from
here.)

Anybody read/view the video?  What company are they pushing?
Anybody got any contacts in their marketing dept? ...

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 43128
Subject: Re: Architecture for high-level reconfigurable computing
From: Keith R. Williams <krw@btv.ibm.com>
Date: Tue, 14 May 2002 13:59:39 -0400
Links: << >>  << T >>  << A >>
In article <3CE13DB0.F6A37653@xilinx.com>, Peter.Alfke@xilinx.com 
says...
> 
> 
> "Keith R. Williams" wrote:
> 
> > Fuses?  The problem then moves to test, but it's been done.
> 
> Fuses are ugly:

Crypto stuff tends to be ugly. Batteries have their ugly side 
too (flammability, waste hazard, PO'd customers...). 

> 1. take lots of current to blow (big drivers)

True, though it is possible. 

> 2. are not good for keeping a secret ( easily detected )

It's done for cryptographically strong data (e.g. private keys) in FIPS 
140-1 level-4 crypto equipment. Secrets are a pretty big deal in this 
application.

> 3. are inherently one-time-programmable, which does not sit well with the basic
> concept of our FPGAs

A OTP key doesn't preclude a modified bitstream. The bitstream 
generator must know about it, of course. The key could even be blown at 
module test before shipment to company X under contract Y.  Ugly, to be 
sure, but possible.  

The only issue I see here is whether or not customers are willing to 
pay for security.  Of course, the question becomes, how much security 
at what cost? Xilinx has made a stab at it.

...been on all sides of this one.

----
  Keith (not speaking for IBM)
 
 

Article: 43129
Subject: Re: Neverending ISA bus interface drama, Spartan-II
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Tue, 14 May 2002 19:36:05 +0100
Links: << >>  << T >>  << A >>


Sean wrote:

> I'm convinced there is an anti-electical engineering field that passes
> through the lab at regular intervals :)
>

<snip>

Have you tried the idea of:

o Defining the outputs to be open-drain

assign od_out = od ? 1'bz : 1'b0;

o Setting them to LVTTL-16ma

o Using strong-ish pullups at about 330-470R. The actual value depends on the capacitive loading
of the ISA data bus. 470R & 50pF would give ~25nsec to 3.5V.

o Then maybe the Peter A. accelerated o/d trick.

For further investigation I'd suggest:

(1) Taking the output of the internal FPGA register used for your test to some external pins so
you can check that the writes are doing what you think they are.

(2) If you're not already using one then get hold of a digital storage 'scope (DSO) to check the
voltage levels of the outputs and their timing wrt IORD*. A logic analyser timing trace would do
as long as the LA's inputs had variable thresholds.




Article: 43130
Subject: Re: Architecture for high-level reconfigurable computing
From: micahjd@users.sourceforge.net (Micah Dowty)
Date: 14 May 2002 11:37:40 -0700
Links: << >>  << T >>  << A >>
Neil Franklin <neil@franklin.ch.remove> wrote in message news:<6ubsbjlqzk.fsf@chonsp.franklin.ch>...
> 
> That open source programmers accept non-supported stuff is a new thing
> in FPGA development circles. They have still got to get used to our
> different culture. Give them a bit of time and they will digest it.
> 

Yep, hopefully. The extent of my FPGA experience has been a little
work on video processing with the XC4000 and Spartan II families. I'm
mostly a software guy.. I started a GUI for embedded systems a while
ago (http://picogui.org) and among other things I wanted to experiment
with a hardware version of its rendering pipeline, that could do
things like compositing and primitive sorting in real time. But I'm
also a fan of reconfigurable computing.. and of course I like to
generalize everything :)

> Try the following stuff:
...
> Looking at how long your project will take (just defining your
> language and how to split it CPU/FPGA), I will most likely have
> that already finished before you get around to doing it.
> 
> It has been on my project list for about 1 year, and now that my
> job change is through, I can start off doing it.
> 
> http://neil.franklin.ch/Projects/VirtexTools/
> 

Very nifty!
I had actually seen your work a few days ago, but didn't know whether
it was still active. Also, I knew about JBits, but was under the
impression it could only modify the LUTs and BRAMs in existing
designs, not route new ones. If JBits can in fact to routing, it
sounds like a good interim solution to use until you reverse engineer
the bitstream so we can have faster and open tools.

--Micah

Article: 43131
Subject: Re: Neverending ISA bus interface drama, Spartan-II
From: Iwo Mergler <Iwo.mergler@soton.sc.philips.com>
Date: Tue, 14 May 2002 19:41:38 +0100
Links: << >>  << T >>  << A >>
Sean wrote:
> 
> I'm convinced there is an anti-electical engineering field that passes
> through the lab at regular intervals :)
> 
> Anyway, here's a little history.  When I at first couldn't even get
> the bus working the PCI33_5 standard to work it appeared we had no
> problems with voltage levels.  Everything was at 3.3V which should
> have been enough for the ISA bus, but our erros clearly indicated we
> were getting stuck at zero errors beause all of our erroneous data was
> values that could be derived from the input simply by dropping some of
> the 1's to 0's.  However, we could never see these ourselves.  This is
> why I decided to add the 4.7k ohm pull-up resistors so the bus would
> go to a full 5V.  This worked, and the bus began to operate.  Last
> week (well, two weeks ago now), I had finished the project but was
> messing around with it some more and discovered that now it worked
> without the pull-up resistors.  I haven't bothered to look at it with
> a scope lately since the last time I did it we couldn't see anything
> that should have been causing abnormal operation in the first place.
> 
> Two weeks ago I also discovered that LVTTL doesn't work at all.  I had
> originally switched from LVTTL to PCI33_5 because I was basing my core
> off of one from a part at Mesa Electronics, in which they used
> PCI33_5.  (They were also trying to assign slew rate and drive current
> via the contraint file, but I don't think that's possible with
> PCI33_5, only with the LVTTL io buffers).  Anyway, I just stuck with
> the PCI33_5 since I knew someone else had gotten the bus working using
> it.
> 
> The LVTTL not working is a mystery to me though.  The behavior it
> exhibits is this.  I have a C++ programming writing and reading a
> value into the FPGA.  It reports the success or failure of each write
> and read (whether it read the same thing it just wrote into the FPGA)
> into a file along with the the value of each write and read
> transaction.  I'm doing 8-bit transactions at the moment so I
> basically just have a counter that counts from 0 - 255 and writes and
> reads the value.  As I said, the implementation using PCI33_5 works
> fine, success every time.  However, the LVTTL log file is a string of
> all failures except for the first one.  This is because the LVTTL port
> always gives me a value of zero on a read, and the first test value is
> always a zero so it says it is correct.  Of course, it doesn't help to
> have a port that only lets the PC read in a zero regardless of the
> actual data value.  Occasionlly, no more than once through each run, I
> will see something other than a zero on one of the PC reads, but it's
> never the correct value anyway, so it still results in an error.
> These are just noteworthy merely because it's not just a zero.
> 
> This occurs even when I have the pull-up resistors to 5V on the bus so
> it can't be merely a voltage level issue.  I wouldn't expect that
> anyway since it's for the most part a consistant zero on the port and
> not some random derivative of the input value with some random stuck
> at zero faults.
> 
> I also know it's not my logic as I use the same VHDL and C++ code for
> both tests, I just synthesize one using PCI33_5 and one using LVTTL.
> 
> I guess my only other course of action is to try and delve in with the
> oscilloscope again.  It didn't really tell me anything useful last
> time so I have my doubts.
> 
> If I knew the drive current that PCI33_5 uses though I may not even
> have to worry about the LVTTL though.  So if anyone knows what the
> standard drive current on a PCI33_5 output buffer is I'd be grateful,
> since I can't seem to find it anywhere :)
> 

I would guess you've got a borderline timing problem. ISA is really
not that problematic... Something like violating setup/hold times on 
the bus maybe? 

I suppose you resynchronise all input signals in your FPGA - ISA may
be asynchronous to your local clock.

BTW, if you want 5V levels use a level converter (the safe way) or
use pull-ups with *open drain* pins (the quick and dirty way). You 
may even drive the pin up to 3.3V and then release it to float to 5V 
by pull-up. I  think i've seen a Xilinx appnote on that topic.

Kind regards,

Iwo

Article: 43132
Subject: Re: Architecture for high-level reconfigurable computing
From: Peter Alfke <Peter.Alfke@xilinx.com>
Date: Tue, 14 May 2002 12:12:59 -0700
Links: << >>  << T >>  << A >>
I do not have the statistics about what users do with our parts, nobody really has.
That's the beauty of FPGAs; users can do anything they please, without telling us
about it ( life support equipment being explicitly excluded, see one of the first
pages of our data book).
So I don't know this for sure, but I venture to guess that there are more people who
have voiced opinions here about battery reliability and alternate security solutions,
than there are designers who have actually used the free encryption we offer.
Security was often "very important" while it was not available, but then turned into
a big yawn when it became available.
Maybe that's just human nature...

Peter Alfke, Xilinx Applications




Article: 43133
Subject: Altera/Quartus II: unconditional loop?
From: Ted Bronson <tedbronson@hotmail.com>
Date: Tue, 14 May 2002 15:37:56 -0400
Links: << >>  << T >>  << A >>
Greetings,

I'm a bit new to all this... why doesn't the Quartus II
support the "loop <body> end loop;" loop??

Is there a way to do something like this?

I've got several signals, in different orders, that I
want to be sensitive to.

Any suggestions?

Thanks!


Article: 43134
Subject: Re: Architecture for high-level reconfigurable computing
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Tue, 14 May 2002 19:39:04 GMT
Links: << >>  << T >>  << A >>
Yes the other way in C is to have functions that run in parallel like
threads. The compiler must be smart enough to infer real parallel hardware.
Also if you take the list operator and define the behavior as fully parallel
then C does not seem sequential.

Steve


"news.bellatlantic.net" <vze3qgji@verizon.net> wrote in message
news:tr0E8.13475$Q87.4354@nwrddc02.gnilink.net...
> There's a big difference between having the programmer specify the
> parallelism, vs. hoping someday someone will figure out algorithms so that
a
> compiler that can find it.  Many man-years have been spent trying to make
> compilers that can find the inherent parallelism in a program, and so far
> only some loop-level parallelism can be exploited.  Adding features to a
> language like fork and join with explicitly stated synchronization will
get
> you to useful parallelism far sooner than waiting for the compiler that
does
> it automatically.  -Stan




Article: 43135
Subject: Re: Architecture for high-level reconfigurable computing
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Tue, 14 May 2002 19:47:22 GMT
Links: << >>  << T >>  << A >>
As FPGAs get more popular people will just get together and figure out the
bitstream anyway. So why not just publish the whole thing and get it over
with? All your doing is making people jump through hoops. With the little
information already published people are already making tools. Imagine if
Intel had you encrypt all your programs because some people were afraid of
having their programs decompiled? The software world would be in the stone
age. And that is where we are as far as programming FPGAs. Maybe someone at
GNU will start hacking away. I don't think it would take much.

Steve


"Peter Alfke" <Peter.Alfke@xilinx.com> wrote in message
news:3CE03B81.B6624D70@xilinx.com...


> 1.
> It might make some users feel vulnerable that their design can be
> reverse-engineered and then slightly modified to hide the rip-off.
>
> 2.
> It might expose Xilinx to unreasonable and unsupportable user questions,
> especially when they painted themselves into a corner. And he who sells
the
> chips ultimately is stuck with the cry for help...
>
> Peter Alfke
>



Article: 43136
Subject: Re: Altera/Quartus II: unconditional loop?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Tue, 14 May 2002 13:00:29 -0700
Links: << >>  << T >>  << A >>
Ted Bronson wrote:


> 
> I'm a bit new to all this... why doesn't the Quartus II
> support the "loop <body> end loop;" loop?


> I've got several signals, in different orders, that I
> want to be sensitive to.



Quartus II does place and route on completed designs.
It is *very* limited for HDL design entry and
has *no* provisions for HDL simulation.

It does have a good schematic editor.

If you want to do HDL design entry you will need
to learn Verilog or VHDL and get HDL simulation
and synthesis tools.

    -- Mike Treseler


Article: 43137
Subject: Re: Architecture for high-level reconfigurable computing
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 14 May 2002 20:08:54 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <37ce351d.0205141037.b48f444@posting.google.com>,
Micah Dowty <micahjd@users.sourceforge.net> wrote:
>Very nifty!
>I had actually seen your work a few days ago, but didn't know whether
>it was still active. Also, I knew about JBits, but was under the
>impression it could only modify the LUTs and BRAMs in existing
>designs, not route new ones. If JBits can in fact to routing, it
>sounds like a good interim solution to use until you reverse engineer
>the bitstream so we can have faster and open tools.

It can modify the PiPs as well, giving complete control, and there is
a high level module to do routing.


-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 43138
Subject: Re: Architecture for high-level reconfigurable computing
From: Neil Franklin <neil@franklin.ch.remove>
Date: 14 May 2002 22:15:48 +0200
Links: << >>  << T >>  << A >>
John Williams <j2.williams@qut.edu.au> writes:

> things about the bitstream format.  In particular, we found a simple
> method that could, in principle, be used to reverse engineer the
> bitstream.  Or more precisely, reverse engineer the relationship between
> a placed and routed design, and the corresponding bitstream.  The idea
> of actually developing a tool to do the constrained routing etc just
> makes my head hurt.

For Virtex it is a bit simpler. The JBits docs actually show exactly
how many wires and PIPs the routing consists of. And the library
allows discovering them individually.

For an _partial_ sketch (no hex and long lines), derived soley from
that docu, no experimentation yet, see this:

http://neil.franklin.ch/Projects/VirtexTools/Virtex-CLB-PIPs


> Anyway let me know if you are really interested to hear more about the
> bitstream stuff.

Allways interested here.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Make your code truely free: put it into the public domain

Article: 43139
Subject: Re: Architecture for high-level reconfigurable computing
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Tue, 14 May 2002 20:20:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <MPG.174b1a664828c90198979e@enews.newsguy.com>,
Keith R. Williams  <krw@btv.ibm.com> wrote:

>> 2. are not good for keeping a secret ( easily detected )
>
>It's done for cryptographically strong data (e.g. private keys) in FIPS 
>140-1 level-4 crypto equipment. Secrets are a pretty big deal in this 
>application.

Then again, look at the massive physical packaging to maintain that
level of security in the IBM 4758 (Is this what you are referring
to?).

Also, I thought that they used SRAM, simply because it is much easier
to zero out the contents when the physical tamper-sensor is disturbed,
keeping the SRAM bits from being burned in by the use of occasional
data moves.


I wonder what sort of ram-keeper/ram-saver is used in the Virtex II
mechanism?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 43140
Subject: Re: Architecture for high-level reconfigurable computing
From: Micah Dowty <micahjd@users.sourceforge.net>
Date: Tue, 14 May 2002 20:23:22 GMT
Links: << >>  << T >>  << A >>
That's pretty much what I was figuring. You would be able to program
software objects in any existing language, and hardware or software
objects in the new language.

Existing software languages could use a shared library to send/recieve
messages with other objects (software or hardware) and native message
sending support could be used where applicable (in languages like
Objective C).

The new language would compile each object to software and to hardware.
The decision of which objects to implement in hardware could be made
automatically (by available FPGA space and software CPU utilization) or
hinted by the programmer.

Each software/hardware object would share a relatively low speed
message passing bus, plus there could be some way to do faster direct
data transfer. This could be done between hardware components by directly
routing wires between the objects, and it could be done between hardware
and software objects using DMA.

I would prefer to stay away from .NET, for a few reasons...
 - For software-only components any language should work
 - For the software/hardware components, I haven't seen a language that
really satisfies the requirements fully
 - I'm an open source geek, I'd rather not use a microsoft product :)

That said, I'll be thinking about the design of this language. Since it
needs to be easy to use for non-EE software people, there needs to be an
easy way to specify sequential operation, but parallel operations must be
intuitive enough that the programmer doesn't overlook them. Handel-C fits
this bill, but besides the problem of it being proprietary, it doesn't
support the dynamically loaded objects and message passing. Maybe what we
need is something like a Handel-C++.

On Mon, 13 May 2002 15:05:43 -0600, Jim Granville wrote:

>  The best 'horizon' approach would be
> 
> - A language that is inherently parallel and capable of HW description
>   (More than one language support would be good : some problems suit
>    some languages better than others).
> 
> - A three way path for that language, to allow
>   a) Run on a PC/ARM/PPC etc HW, ie Hard core with maximal resource b)
>   Run on a soft-core, ie FPGA core with minimal resource c) Run in FPGA
>   HW
> 
>  Some discussion on Java in FPGA's is already underway, another
> pathway would be to implement .NET MSIL in FPGA/Softcore combination.
> 
>  .NET is new, but already looks a more stable pivot point than Java
> flavours,
> and .NET has good language support already - See
> 
> http://msdn.microsoft.com/vstudio/partners/language/default.asp
> 
>  This would lead to .NET core(s) in FPGA, with key code sections chosen
> as
> FPGA-Macros, running as a system.
> 
>  jg

Article: 43141
Subject: Re: Architecture for high-level reconfigurable computing
From: Keith R. Williams <krw@btv.ibm.com>
Date: Tue, 14 May 2002 16:31:18 -0400
Links: << >>  << T >>  << A >>
In article <3CE161BB.801C40DB@xilinx.com>, Peter.Alfke@xilinx.com 
says...
> I do not have the statistics about what users do with our parts, nobody really has.

Are FAEs encouraged to feed back such requirements? How about cost 
sensitivity to real solutions?  Fuses are cheap, by the dozen.  
However, if there are billions unused, then the dozen used get 
expensive.

> That's the beauty of FPGAs; users can do anything they please, without telling us
> about it ( life support equipment being explicitly excluded, see one of the first
> pages of our data book).

The first time I saw the "life support" issue was when perusing a Nat-
Semi databook some thirty years ago.  I thought it strange, until I 
thought about it a few microseconds.  

> So I don't know this for sure, but I venture to guess that there are more people who
> have voiced opinions here about battery reliability and alternate security solutions,
> than there are designers who have actually used the free encryption we offer.

I've dealt with batteries.  What a PITA!  I'd be more wary about PO'd 
customers than a few stealing the products.  When it's crypto stuff, 
the customer's data is far more important than my design.  The tables 
turn.  

> Security was often "very important" while it was not available, but then turned into
> a big yawn when it became available.

Honestly, it's of no concern for the FPGA application I've had. I can 
see where it's a nice feature. 

Don't get me wrong, I'm not complaining about Xilinx' design point.  It 
seems to be a cheap solution to at least part of the problem. Anything 
more complex could cost everyone. I don't think that's the right answer 
for the market. My only point is that there are solutions to this 
problem, though perhaps not simple.  Similar things have been done 
(though I don't know about the IP status).

> Maybe that's just human nature...

True.  "I want it, and I want it free" is human nature. "I need it and 
now" is definitely PHB nature. ;-)

----
  Keith (not speaking for IBM)

 

Article: 43142
Subject: Re: Architecture for high-level reconfigurable computing
From: Neil Franklin <neil@franklin.ch.remove>
Date: 14 May 2002 22:34:37 +0200
Links: << >>  << T >>  << A >>
micahjd@users.sourceforge.net (Micah Dowty) writes:

> Neil Franklin <neil@franklin.ch.remove> wrote in message news:<6ubsbjlqzk.fsf@chonsp.franklin.ch>...
> >
> > That open source programmers accept non-supported stuff is a new thing
> > in FPGA development circles. They have still got to get used to our
> > different culture. Give them a bit of time and they will digest it.
>
> mostly a software guy.. I started a GUI for embedded systems a while
> ago (http://picogui.org)

I have heard of its name, but never looked into its details.


> and among other things I wanted to experiment
> with a hardware version of its rendering pipeline,

An open source graphics accelerator, nice.


> also a fan of reconfigurable computing.. and of course I like to
> generalize everything :)

What hacker doesn't? ;-)


> > http://neil.franklin.ch/Projects/VirtexTools/
>
> I had actually seen your work a few days ago, but didn't know whether
> it was still active.

Not yet active. Waiting for the 3rd milestone of the PDP-10 before I
really start on it. To follow current state of activity look at:

http://neil.franklin.ch/Projects/VirtexTools/Logfile
(freshly updated, just now)

And for the PDP-10 project that is competing with it for my time look at:

http://neil.franklin.ch/Projects/PDP-10/Logfile


> Also, I knew about JBits, but was under the
> impression it could only modify the LUTs and BRAMs in existing
> designs, not route new ones.

My entire PDP-10 clone FPGA CPU is written using only JBits. YOu can
look at the source at:

http://neil.franklin.ch/Projects/PDP-10/pdp10.java


Limit is presently, that you need an empty bitfile to modify
(programming is debugging an empty file, and so ...), and there
are only XCV300/800/1000 coming with JBits. No Spartan-II compatible
sizes.


> If JBits can in fact to routing, it
> sounds like a good interim solution to use until you reverse engineer
> the bitstream so we can have faster and open tools.

It can and it is.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Sysadmin, Archer, Roleplayer
- Make your code truely free: put it into the public domain

Article: 43143
Subject: Re: Altera/Quartus II: unconditional loop?
From: Dines Justesen <dines@aub.dk>
Date: 14 May 2002 21:06:27 GMT
Links: << >>  << T >>  << A >>
> I'm a bit new to all this... why doesn't the Quartus II
> support the "loop <body> end loop;" loop??

When synthesizing VHDL loops inside a process will result in the logic 
inside the loop being repeated as many time as the code is looped. So if 
you loop a statement which generates and adder 16 times, it will generally 
create 16 adders. So an unconditional loop will keep generating new 
hardware, which wont fit in a any device. 

Suggesting an alternative way of implementing your function would be easier 
if you posted the code you have now, but I think that a process with the 
right sensitivity lis (and no loops) might be the soltion. (A process with 
a sensitivity list will loop everytime one of the signals in the 
sensitivity list changes)

Dines

-- 
---------------------------------------------------
 Dines Justesen | dines@aub.dk | www.aub.dk/~dines
---------------------------------------------------

Article: 43144
Subject: Re: Architecture for high-level reconfigurable computing
From: Micah Dowty <micahjd@users.sourceforge.net>
Date: Tue, 14 May 2002 21:11:51 GMT
Links: << >>  << T >>  << A >>
On Tue, 14 May 2002 14:34:37 -0600, Neil Franklin wrote:

>> If JBits can in fact to routing, it
>> sounds like a good interim solution to use until you reverse engineer
>> the bitstream so we can have faster and open tools.
> 
> It can and it is.
> 

Sounds like it would be useful to have an intermediate format that could
be fed into a JBits-based tool or into your open tools. Are there already
any good formats for this?

--Micah

Article: 43145
Subject: Re: bug in XST ?
From: Tullio Grassi <tullio@physics.umd.edu>
Date: Tue, 14 May 2002 17:14:38 -0400
Links: << >>  << T >>  << A >>
Do not pay attention to the names of the signals, 
they refer to something else.
 In fact Xilinx guys confirmed that the bug is 
real and will be fixed in fall.



Tullio





Kevin Brace wrote:

> 
> Have you simulated your design after synthesizing it with FPGA Compiler
> II?
> I feel like it won't function at all because according to Stuart
> Sutherland's Verilog HDL Quick Reference Guide
> (http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_top.html),
> bufif1's syntax will be the following.
> 
> bufif1 (1_output, 1_input, 1_control)
> 
> This is what you got in your code.
> 
> bufif1  buf_D_0         (LocData[0],    D_OUT[0],       LocDir);
> 
> I think it should be instead,
> 
> bufif1  buf_D_0 (D_OUT[0], LocData[0], LocDir);
> 
>  ...

-- 

 Tullio Grassi
======================================
Univ. of Maryland - Dept. of Physics
College Park, MD 20742 - US
Tel +1 301 405 5970
Fax +1 301 699 9195
======================================

Article: 43146
Subject: verilof parameter and XST
From: Tullio Grassi <tullio@physics.umd.edu>
Date: Tue, 14 May 2002 17:24:53 -0400
Links: << >>  << T >>  << A >>
Hi,
 Verilog allows a construct to pass parameters to lower level modules:

//////////////////////////////////////
  parameter  
    PARAM1    =  128;

  defparam
   my_lower_module.PARAM1  = PARAM1;
//////////////////////////////////////

that works as long as inside  my_lower_module
 PARAM1 is defined again.
This can be repeted for several modules down the hierarchy,
and is very useful for heavy hierarchical designs.

I've had problems using it with XST (ISE4.2).
It looks like XST selects the value randomly along
the hierarchy, rather than at the top level.

Anybody  had similar problems ?
-- 

Tullio Grassi

======================================
Univ. of Maryland - Dept. of Physics
College Park, MD 20742 - US
Tel +1 301 405 5970
Fax +1 301 699 9195
======================================

Article: 43147
Subject: Re: Architecture for high-level reconfigurable computing
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Wed, 15 May 2002 09:45:13 +1200
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> "Keith R. Williams" wrote:
> 
> > Fuses?  The problem then moves to test, but it's been done.
> 
> Fuses are ugly:
> 1. take lots of current to blow (big drivers)
> 2. are not good for keeping a secret ( easily detected )
> 3. are inherently one-time-programmable, which does not sit well with the basic
> concept of our FPGAs
> 
> Peter Alfke

 On a more up-to-date front than fuses, has Xilinx looked at this :

http://www.viragelogic.com/products/compilers/novea/index.jsp

http://www.viragelogic.com/products/datasheets/NOVeA_family_datasheet.pdf

They claim TSMC process compatible, and :
# NOVeA is a non-volatile memory that can be reprogrammed multiple 
# times. Additionally, this memory can be embedded into a SoC and can be 
# fabricated in a state-of-the-art, leading edge standard logic process 
# with no additional process steps. Integrating NOVeA will help reduce 
# overall system costs, increase performance and security and greatly 
# decrease the time to market. 

 This is not large capacity, so not suited to the whole bitstream, but 
does look a candidate for security, and serial numbering applications.

 Xilinx could even use this to put another spin on their Yield-Recovery 
offerings of 'Device does not fully pass test' pathways :)

 ie Turn the FPGA into a Hard Drive in nature, with 'bad sector'
mapping.
 -- oops, now it's in the public domain, I can't patent this.


-jg

Article: 43148
Subject: Re: Architecture for high-level reconfigurable computing
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 14 May 2002 14:57:28 -0700
Links: << >>  << T >>  << A >>
Jim,

Yup.  Been there, done that.  No news.  Nothing there.

Austin

Jim Granville wrote:

> Peter Alfke wrote:
> >
> > "Keith R. Williams" wrote:
> >
> > > Fuses?  The problem then moves to test, but it's been done.
> >
> > Fuses are ugly:
> > 1. take lots of current to blow (big drivers)
> > 2. are not good for keeping a secret ( easily detected )
> > 3. are inherently one-time-programmable, which does not sit well with the basic
> > concept of our FPGAs
> >
> > Peter Alfke
>
>  On a more up-to-date front than fuses, has Xilinx looked at this :
>
> http://www.viragelogic.com/products/compilers/novea/index.jsp
>
> http://www.viragelogic.com/products/datasheets/NOVeA_family_datasheet.pdf
>
> They claim TSMC process compatible, and :
> # NOVeA is a non-volatile memory that can be reprogrammed multiple
> # times. Additionally, this memory can be embedded into a SoC and can be
> # fabricated in a state-of-the-art, leading edge standard logic process
> # with no additional process steps. Integrating NOVeA will help reduce
> # overall system costs, increase performance and security and greatly
> # decrease the time to market.
>
>  This is not large capacity, so not suited to the whole bitstream, but
> does look a candidate for security, and serial numbering applications.
>
>  Xilinx could even use this to put another spin on their Yield-Recovery
> offerings of 'Device does not fully pass test' pathways :)
>
>  ie Turn the FPGA into a Hard Drive in nature, with 'bad sector'
> mapping.
>  -- oops, now it's in the public domain, I can't patent this.
>
> -jg


Article: 43149
Subject: Please help me figure out serial prom problem
From: "C.W. THomas" <cwthomas@bittware.com>
Date: Tue, 14 May 2002 18:11:07 -0400
Links: << >>  << T >>  << A >>


HI;

Thanks for reading this.  I have been trying to program a sartan II chain.

I am using the following to build the prom file...

# Created 2002/05/14 17:35:20
BeginProm
  Type   Serial
  Format MCS-86
  FillValue FF
  Info MaxAddress 0x000CBD73
  Devices FullCustom XC18V04 XC1704L
  BeginChain
    StartAddress    0x00000000
    Direction       UP
    Info EndAddress 0x000CBD73
    Info Size       0x000CBD74
    File "C:\dram_top.bit"
    File "C:\dram_top.bit"
    File "C:\dram_top.bit"
    File "C:\pci_top.bit"
    File "C:\dram_top.bit"
  EndChain
EndProm

There are  5 spartan IIs  chained together as :    prom, prom,
dram,dram,dram,pci,dram
I can see data appearing to load into the spartans when they try to config.
I have no problem loading thre spartans or proms from the DLC7 paralell
cable.and it says the proms verify OK.

Questiuon:
 Do I set the cclk or jtag clk option when making a bit stream for use in
the prom.  I Am using master slave mode or at least trying to.   How does
the promgen utility lknow how to break the bit files up to go in the right
prom,  do I load them in the same order as I would using the JTAG loader to
load the individual spartans?


Thanks

any help is appreciated.


C.W. Thomas





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