pcb&bitstream

[glen herrmannsfeldt]

Ed McGettigan <ed.mcgettigan@xilinx.com> wrote:
(snip)

The same level of bistream architecture disclosure or partial
reconfiguration support is not available from any other FPGA vendor.
However what you will not find in this material are direct
relationships between any specific bit and a specific functionality.
This information is extremely complex, has a high level of variability
within a FPGA family and changes completely from one family to
another. This isn't the same as documentating an ISA and a register
map for a CPU or peripheral device that has one task and runs at one
clock frequency it would be 10,000 times more complex to fully
document the entire FPGA configuration map.

Well, some processor descriptions are pretty complicated these
days, so 10,000 might be a little high. I have the intel books
for itanium, and it isn't just a little more than IA32.

Also, since the FPGA is made up of a large number of CLBs, each
pretty much the same, you don't need to separately describe each.

In the XC4000 days, I was working on a design that would have
used a dynamic bitstream, though most of it was data in look-up
tables. That was for a systolic-array search processor, where the
search pattern data was loaded into little ROMs. Some that
I thought of also needed different configurations for the
carry chain, but that used the XC4000 style carry chain, which
wasn't continued into later families.

There were attempts to develop non-ISE design flows and a research
vehicle called Jbits was developed and released by Xilinx that
supported some of the Virtex, Virtex-E and Virtex-II families (no
support for Spartan-3E that I am aware of). Jbits was not extremely
useful beyond academic research as it lacked elements that would allow
for building a robust and reliable design, features like simulation
and timing analysis. No similiar vehicle has ever been released by
another FPGA vendor.

I don't know what the OP is trying to do at all. I am still
interested in systolic arrays, some of which require dynamic
generation of LUT (ROM) data. The rest of the bitstream is
constant.

-- glen

 

[geobsd]

I think you should try to get a more realistic and less emotional view
of things.
i'm realistic, do you have an idea of easy i am ?

re Thomas

 

[geobsd]

hi glen
for now i'm searching a pcb for the 5 spartan (hard)
i'll look later on your arrays
going to sleep !
i hope there will be else interesting comments on dynamic bit-stream
@bientôt

 

[whygee]

geobsd wrote:

thanks again Ed !
we're all watching you and wishing you good luck.
you seem to be passionate and driven by ideals,
so at least something good must result from this
i am, i have no hate for Ed, the poor should not really understand why
i'm not happy with my fpga...
i think he understands your problem,

which explains his latest, very detailed and empathic answer.
FPGA are technology marvels but they come at a high initial cost,
for example, overall, I spent more for computer hardware and software
than for FPGA chips themselves. it's a big investment at many levels,
time, money, mentally... But when it's well done, and after quite a lot
of time (sometimes years) it's really great and empowering
and you appreciate that several restrictions of the vendors
are nothing compared to the design freedom they provide you with.

We understand that you expect to be able to use the chips
that you have bought, we all expect that, but we often
have to compromise and the FPGA field is the harshest domain
in this respect.

I don't lose hope, as some FPGA startups
sometimes appear with interesting alternatives.
For example, SiliconBlue had done some things right,
but i have had no contact since at least a year :-(

anyway i usualy do what i said, maybe i'm nothing maybe not
we become what we do

so you know what you have to do now.

If you are in/around Paris, there were FPGA workshops
at the /tmp/lab where newcomers were introduced to the S3 (by coincidence).
http://www.tmplab.org/2009/10/21/fpga-workshop-4-behind-the-scenes-november-8/
No idea if Sébastien / Lekernel will organise other workshops like this
but there may be hackers/bricoleurs around Paris who could help you a bit.
I may have another address or two.

Nobody is going to do things for you, however, but at least certain kinds
of knowledge are free

@bientôt
yg

--
http://ygdes.com / http://yasep.org

 

[rickman]

On Mar 12, 5:46 pm, geobsd <geobsd...@gmail.com> wrote:

I think you should try to get a more realistic and less emotional view
of things.

i'm realistic, do you have an idea of easy i am ?
re Thomas

I think I have an idea of what you are looking to do. You want to
connect an FPGA to your tablet computer to use as an attached
coprocessor that is programmed on the fly by the CPU in the tablet.
But not just "programmed", the programming is to be calculated on the
fly as well.

You have made two mistakes. One is thinking that you would find a way
to directly connect FPGA chips directly to a tablet computer.
Instead, you should buy a board or other unit that has an interface to
your tablet computer, such as Ethernet or USB. Otherwise how would
you ever hope to connect the FPGA? Even if your tablet has some
internal interface that you want to use, how would you expect to
connect that to the FPGA which is only designed to be soldered onto a
PCB? Some internal interfaces a tablet might have are a memory socket
(likely filled with memory though) and SATA which would be a nice high
speed interface, but very complex to add to an FPGA. So your external
interfaces are most likely the best way to go.

The second mistake is thinking that you could generate a bitstream
without running one of the standard OS like Linux or Windows. Yes,
the FPGA makers hold the bitstream format as a proprietary secret.
Opening this up would create some competition concerns, but more
likely they are worried that bad bitstreams would cause reliability
issues since a bad bitstream has potential of frying an FPGA. It is
certainly possible to generate an EDIF description of a design
complete with location info for each logic block within a design, at
least I belief that is true. To turn this into a bitstream requires
at least some proprietary software which will only run on Linux or
Windows. However... if you have the perseverance, it should be
possible to analyze small changes in the source and analyze the
changes in the bitstream to learn the location and function of each
control point. It would be a huge job and I believe others have
attempted it with some degree of success. Further this changes with
each new family if not each part.

So there it is in a nutshell. If you really want to do it, you just
need to get a free version of the tools and start cranking out designs
until your fingers and eyes bleed! Or maybe you can figure out a way
to automate this?

Good luck!

Rick

 

[geobsd]

hi rick

I think I have an idea of what you are looking to do.  You want to
connect an FPGA to your tablet computer to use as an attached
coprocessor that is programmed on the fly by the CPU in the tablet.
But not just "programmed", the programming is to be calculated on the
fly as well.
the plan was to have a pcb where put the 5 spartan and put it in the

tablet.
for some computing your description is ok !

You have made two mistakes.
i have made more, but learning come with it (often)

The second mistake is thinking that you could generate a bitstream
without running one of the standard OS like Linux or Windows.  Yes,
the FPGA makers hold the bitstream format as a proprietary secret.
Opening this up would create some competition concerns, but more
likely they are worried that bad bitstreams would cause reliability
issues since a bad bitstream has potential of frying an FPGA.
i think if users make a bad use of fgpa the makers are not concerned

the competition concerns are not a real problem here, fpga makers
surelly use strong engines to see the work of competitors

 It is
certainly possible to generate an EDIF description of a design
complete with location info for each logic block within a design, at
least I belief that is true.  To turn this into a bitstream requires
at least some proprietary software which will only run on Linux or
Windows.  However... if you have the perseverance, it should be
possible to analyze small changes in the source and analyze the
changes in the bitstream to learn the location and function of each
control point.  It would be a huge job and I believe others have
attempted it with some degree of success.  Further this changes with
each new family if not each part.
i understand 2 way more to know my fgpa model in full but it will be

long
with public map fgpas could reach perfection !

So there it is in a nutshell.  If you really want to do it, you just
need to get a free version of the tools and start cranking out designs
until your fingers and eyes bleed!  Or maybe you can figure out a way
to automate this?
i will try my friend

Good luck!
thanks Rick

 

[rickman]

On Mar 13, 7:49 am, geobsd <geobsd...@gmail.com> wrote:

hi rick

I think I have an idea of what you are looking to do.  You want to
connect an FPGA to your tablet computer to use as an attached
coprocessor that is programmed on the fly by the CPU in the tablet.
But not just "programmed", the programming is to be calculated on the
fly as well.

the plan was to have a pcb where put the 5 spartan and put it in the
tablet.
for some computing your description is ok !

Again, there are mistaken assumptions in this idea. First making a
PCB for an FPGA is not the full extent of connecting an FPGA to any
computer, but it is certainly one of the most painful ways of
connecting an FPGA to a computer. It is expensive, time consuming and
laborious. Much easier to connect is a USB device.

The other issue is that you have no idea what interface you will find
inside your tablet or if there will be one at all!

The idea of plopping an FPGA inside the tablet is not a good one
unless you have lots of money to burn.

You have made two mistakes.

i have made more, but learning come with it (often)

The second mistake is thinking that you could generate a bitstream
without running one of the standard OS like Linux or Windows.  Yes,
the FPGA makers hold the bitstream format as a proprietary secret.
Opening this up would create some competition concerns, but more
likely they are worried that bad bitstreams would cause reliability
issues since a bad bitstream has potential of frying an FPGA.

i think if users make a bad use of fgpa the makers are not concerned

Yes, they are very concerned. They have said so. If a customer buys
hundreds or thousands of chips and then wants to return them because
they don't work right and the vendor finds they are all damaged
internally, likely from a bad bitstream, how are they to prove it was
because of the customer using a self designed tool and not because of
the vendor supplied tool? No, they don't care about you doing this
since they likely would never accept a return from you anyway. But
they have to work with very high volume customers who, if the info was
available, may well roll their own tools and cause the FPGA maker all
sorts of difficulties. The possible problems are actually much larger
than this. Don't assume you understand what it is like to be the
vendor.

the competition concerns are not a real problem here, fpga makers
surelly use strong engines to see the work of competitors>  

Again, don't assume you know the vendor. I can't say if the
competition does this or not. I do know it is outside of the tool
license and I strongly suspect it is not worth the effort of the
competitors since there a better ways to learn what they want to
know... like reading patents.

It is
certainly possible to generate an EDIF description of a design
complete with location info for each logic block within a design, at
least I belief that is true.  To turn this into a bitstream requires
at least some proprietary software which will only run on Linux or
Windows.  However... if you have the perseverance, it should be
possible to analyze small changes in the source and analyze the
changes in the bitstream to learn the location and function of each
control point.  It would be a huge job and I believe others have
attempted it with some degree of success.  Further this changes with
each new family if not each part.

i understand 2 way more to know my fgpa model in full but it will be
long
with public map fgpas could reach perfection !

So there it is in a nutshell.  If you really want to do it, you just
need to get a free version of the tools and start cranking out designs
until your fingers and eyes bleed!  Or maybe you can figure out a way
to automate this?

i will try my friend

Good luck!

thanks Rick

Let us know how you get on. Others have started this effort before.
I think there is some sort of a Java tool that lets you manipulate the
final design file before it is turned into a bitstream. I have read
about others using that to make changes to placed and routed designs
to reverse engineer the bitstream.

Once upon a time, there was an FPGA from Xilinx that was intended to
be used for this sort of work. The bitstream was public, IIRC and the
device was designed to prevent damage if the bitstream was corrupted
or just junk. It was popular with the schools, but they ended up
dropping the entire line. I guess the business model for it dried
up.

Rick

 

[geobsd]

Again, there are mistaken assumptions in this idea.  First making a
PCB for an FPGA is not the full extent of connecting an FPGA to any
computer, but it is certainly one of the most painful ways of
connecting an FPGA to a computer.  It is expensive, time consuming and
laborious.  Much easier to connect is a USB device.

The other issue is that you have no idea what interface you will find
inside your tablet or if there will be one at all!

The idea of plopping an FPGA inside the tablet is not a good one
unless you have lots of money to burn.
i will let this idea in a corner the time i learn&practice electronic

to be able to do it myself if i can ...

Yes, they are very concerned.  They have said so.  If a customer buys
hundreds or thousands of chips and then wants to return them because
they don't work right and the vendor finds they are all damaged
internally, likely from a bad bitstream, how are they to prove it was
because of the customer using a self designed tool and not because of
the vendor supplied tool?
i didn't think about not honnest peoples sorry rick

Again, don't assume you know the vendor.  I can't say if the
competition does this or not.  I do know it is outside of the tool
license and I strongly suspect it is not worth the effort of the
competitors since there a better ways to learn what they want to
know... like reading patents.
not everything is patented

for example in my country (france) if you import things to study them,
and have an accord, you have no taxe&duty to pay !
i assume to not even know myself (without lie)

Let us know how you get on.  Others have started this effort before.
I think there is some sort of a Java tool that lets you manipulate the
final design file before it is turned into a bitstream.  I have read
about others using that to make changes to placed and routed designs
to reverse engineer the bitstream.
i didn't saw it yet

Once upon a time, there was an FPGA from Xilinx that was intended to
be used for this sort of work.  The bitstream was public, IIRC and the
device was designed to prevent damage if the bitstream was corrupted
or just junk.  It was popular with the schools, but they ended up
dropping the entire line.  I guess the business model for it dried
up.
too bad !

while i have no pcb i can't try on those spartan
i will find the less expensive i can fpga board to begin soon with
fpga
thanks Rick

 

[RCIngham]

[snip]

anyway as you can restrict small consumers to use the hardware you
sell as you want i will restrict all my projects to be open only for
non-xilinx&affiliated companies !
sadly for you i didn't bought altera, you have one week to decide if
you can publish the bit-stream specs of old products before i restrict
all my open-sources projects with a "no-xilinx&al license" !
if xilinx can't respect me cause i'm not a big buyer it's not my
problem !
thanks again Ed !

ROFLMAO!


---------------------------------------
Posted through http://www.FPGARelated.com

 

[kclo4]

Hi,

I think you do things completely in the wrong order, you buy fpga
without knowing how to use them and then complains you can not use
them because they don't want to give you all informations about it.

I also believe your project is quite ambitiuous for a beginner, you
want to create:

-a synthetizer (and doing one that convert algortihm designed in C or
equivalent is not an easy task)
-a place and route tool
-and design a pcb

I believe this represent a lot of different skills, company are
spending millions of dollars to have efficient software with hundred
of engineers working full time on those differents parts, I don't
think a single guy can do it on his own. Ok let's say you can (after
all you probably don't need your tool to be as efficient as
professional one).

You first should design a board and for this you'll find all needed
informations on xilinx website. (if i were you i will directly buy a
dev kit, gain a lot of time and you will have a working board)
Then make some simple design with vendors tools to see how FPGA works.
Learn about FPGA architecture.
Then learn about netlist and try to generate one and compile it.
Then do your software that would be able to generate a netlist
optimized for the co-processing you want to do on the fly.
Then maybe generate bitstream by playing in floorplanner to try to see
how the bitstream describe the interconnection and LUT content of fpga.
(this is the only part were information is not available)

After doing all that I will meet you in Arkham asylium...

 

[Nial Stewart]

If you think that you will get farther in your goal by using FPGAs
from Altera, Lattice, Microsemi (aka Actel), or QuickLogic then you
should absolutely switch over.

Ed, I read this as "Please use someone else's devices so I can stop
answering these ****ing stupid questions".





Nial.

 

[geobsd]

On Mar 14, 12:25 pm, kclo4 <alexis.ga...@gmail.com> wrote:

Hi,

I think you do things completely in the wrong order, you buy fpga
without knowing how to use them and then complains you can not use
them because they don't wan t to give you all informations about it.

i knew they must be "programmed", the restrictions i didn't

I also believe your project is quite ambitiuous for a beginner, you
want to create:

-a synthetizer (and doing one that convert algortihm designed in C or
equivalent is not an easy task)
-a place and route tool
no

i wanted to use chunks of bit-stream assembled in my model conformance
to process in place of the cpu

-and design a pcb
i'm not the first

I believe this represent a lot of different skills, company are
spending millions of dollars to have efficient software with hundred
of engineers working full time on those differents parts, I don'tat'
think a single guy can do it on his own. Ok let's say you can (after
all you probably don't need your tool to be as efficient as
professional one).

let me try before judging

Then maybe generate bitstream by playing in floorplanner to try to see
how the bitstream describe the interconnection and LUT content of fpga.
(this is the only part were information is not available)
that's the problem !

After doing all that I will meet you in Arkham asylium...
why not friends

thanks

 

[Nial Stewart]

My experience with the brand-X sales force leads me to believe that
they have significant training in politeness and political
correctness. Many times I have watched in amazement as impossible
demands were deflected without insult.
I ain't made of that stuff.

Indeed, Ed is showing commendable restraint!


Nial.

 

[NeedCleverHandle]

On Mar 14, 7:52 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:

If you think that you will get farther in your goal by using FPGAs
from Altera, Lattice, Microsemi (aka Actel), or QuickLogic then you
should absolutely switch over.

Ed, I read this as "Please use someone else's devices so I can stop
answering these ****ing stupid questions".



Nial.

My experience with the brand-X sales force leads me to believe that
they have significant training in politeness and political
correctness. Many times I have watched in amazement as impossible
demands were deflected without insult.

I ain't made of that stuff.

RK

 

[Ed McGettigan]

On Mar 14, 7:52 am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:

If you think that you will get farther in your goal by using FPGAs
from Altera, Lattice, Microsemi (aka Actel), or QuickLogic then you
should absolutely switch over.

Ed, I read this as "Please use someone else's devices so I can stop
answering these ****ing stupid questions".



Nial.

Nial, In my defense I did proceed to give a long list of reasons why
switching to another vendor would be a bad idea in this case. IMHO,
if your designing reconfigurable computing applications it would be
foolish to not use Xilinx due to the wealth of material that we
already provide publicly to support these applications.

Ed McGettigan
--
Xilinx Inc.

 

[whygee]

Hi,

geobsd wrote:

On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
"companies have been started and failed over the years
trying to mate FPGAs with CPUs"
http://www.xilinx.com/technology/roadmap/processing-platform.htm
Altera and Actel too have coupled FPGA+CPU chips (as far as i know).

Years ago, there was one family of FPGA with
a PowerPC core, and now ARM is finding its way
in many new products. The market evolves
(it was easier to include the CPU in the FPGA array until recently)
and needs big companies to try (and sometimes fail)

What is your point ?

yg
--
http://ygdes.com / http://yasep.org

 

[geobsd]

On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
"companies have been started and failed over the years
trying to mate FPGAs with CPUs"
http://www.xilinx.com/technology/roadmap/processing-platform.htm

 

[Kolja Sulimma]

On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote:

since a bad bitstream has potential of frying an FPGA.

This argument is invalid.

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I guess the truth is closer to this argument: documenting the
bitstream format
is a lot of work and is likely to create only very few additional
revenue
from customer that are rather support intensive so it simply isn't
worthwhile for
the vendors.

I believe that documenting LUT content locations in the bitstream
would be a good
compromise. It is relatively easy to document and use and not much can
go wrong
and it has a decent amount of applications where it is useful.
OTOH: The introduction of SRL16 made it easy to support LUT-reloading
explicitely in the HDL.

Kolja

 

[Ed McGettigan]

On Mar 14, 12:49 pm, geobsd <geobsd...@gmail.com> wrote:

On 12 Mrz., 05:27, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
"companies have been started and failed over the years
trying to mate FPGAs with CPUs"http://www.xilinx.com/technology/roadmap/processing-platform.htm

Christophe,

When I wrote my original statement I was referring to the system
architecture that you were trying to achieve, that is a high
performance CPU connected directly with a FPGA for dynamic algorithm
acceleration.

Implementing CPUs inside of a FPGA has been a relatively common
occurance as is using a low end CPU or microcontroller to configure
and control the operation of a FPGA. Both of these are very different
from your stated goals.

Altera came out with an initiative called Excalibur that did not last
very long. One version included a hard ARM922T and processor sub-
system with FPGA fabric for soft peripherals. Two other versions with
MIPs and PowerPC were to be released but never were and the ARM
version lasted a very short time in the market. The last leg of this
program was the NIOS soft processor which is still in existence and
recently updated to NIOS-II.

Triscend came out with a product that combined a hard ARM7 processor
with a FPGA fabric. It did not succeed and the IP assets were bought
and the design team hired by Xilinx.

Microsemi (was Actel) had some ARM Cortex M1 and M3 processor
offerings, but the messaging around this was very confusing to me and
it was never clear to me if there was a hard option or if they was
only a soft option. I don't believe that this received much traction
and I don't know what the fate was after the Microsemi acquistion.

Quicklogic had QuickMIPs that included a MIPS32 4Kc processor along
with their anti-fuse fabric. I never saw much activity on this nor
understood why anyone thought that this made sense with an anti-fuse
one-time-programmable part.

Lattice Semiconductor has soft processors called LatticeMico8 and
LatticeMico32.

Xilinx has had a number of forays into this space including the Virtex-
II Pro and Virtex-4 FX families that included 1- hard PowerPC 405
cores. The Virtex-5 FXT family that included 1-2 hard PowerPC 440
cores. Soft processor cores are provided in the form of MicroBlaze
and PicoBlaze and are supported in every FPGA family since Virtex-II.
The next encarnation of a hard processor block will be present in the
recently announced family called Zynq-7000 and include a hard
implementation of dual ARM Cortex-A9 processors along with a FPGA
fabric.

In each of these cases the FPGA fabric and the processor, whether hard
or soft, was treated as a single entity to create a custom set of
peripherals around the processor to meet the needs that an off-the-
shelf processor couldn't.

Ed McGettigan
--
Xilinx Inc.

 

[Ed McGettigan]

On Mar 14, 5:46 pm, Kolja Sulimma <ksuli...@googlemail.com> wrote:

On 13 Mrz., 01:46, rickman <gnu...@gmail.com> wrote:

since a bad bitstream has potential of frying an FPGA.

This argument is invalid.

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I guess the truth is closer to this argument: documenting the
bitstream format
is a lot of work and is likely to create only very few additional
revenue
from customer that are rather support intensive so it simply isn't
worthwhile for
the vendors.

I believe that documenting LUT content locations in the bitstream
would be a good
compromise. It is relatively easy to document and use and not much can
go wrong
and it has a decent amount of applications where it is useful.
OTOH: The introduction of SRL16 made it easy to support LUT-reloading
explicitely in the HDL.

Kolja

You can fry an FPGA with VDHL and vendor synthesis software.
This has been demonstrated at the FPL conference a decade ago.

I am quite surprised about this. Can you provide any additional
material on how this was achieved?

There aren't any scenarios, other than internal tri-state contention,
that I can come up with to make this happen with a proven tool chain.

Ed McGettigan
--
Xilinx Inc.