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 142475

Article: 142475
Subject: Re: Spartan-6 Boards - Your Wish List
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Wed, 12 Aug 2009 08:50:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 10, 12:36=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> We have been looking at the FMC standard but it does have a pile of
> problems for us and our potential customers. This specification was
> written by a group of people all from companies, in the same market
> sectors, and with a very limited vison as a result. Problems as I see
> it:
>
> (1) The specification costs a lot to buy and will limit widespread
> adoption and potential customer base.

The VITA-57.1 specification cost is $75 and is only needed by a board
designer. Having a uniform standard will allow for for wider
collection of FMC modules that can be used on a wider set of boards
for increase adoption.

> (2) The format is very small even on the bigger version.

The LPC (Low Pin Count) version has 68 IOs, 2 Clock Pairs, and 1 MGT
TX/RX + REFCLK.  The HPC (High Pin Count) version has 160 IOs, 4 Clock
Pairs and 10 MGT TX/RX and 2 REFCLKs.  Small is in the eye of the
beholder.  If you need more then you can move into a double wide
configuration.

> (3) A lot of on-module regulation will be needed further limiting what
> else can be done on the module.

I haven't put any voltage regulation on any of the FMC modules that
we've designed so far, but I will on some that are coming up. The CC
(Carrier Card) provides 12V, 3.3V and VADJ (0-3.3V) and the FMC can
provide one voltage back to the CC (VIO_B).  For most FMC this is
enough, but if you need to a 5V rail then you will need to convert the
12V to 5V.

Note: For Xilinx CC, we are fixing the VADJ supply to 2.5V to be
compatible for both our Virtex-6 and Spartan-6 families IO standards.

> (4) On small and medium size devices, e.g. most Spartans, it uses up
> most I/O that we would normally use for our own headers and we can't
> maintain our support for existing customers.

There is no requirement that you must fill up all of the IOs on the
LPC or HPC.  The only requirement is that you start with the LA_00 to
enable the highest degree of compatability.

> (5) Connectors are very expensive and single source. I will say Samtec
> is a very good supplier of connectors but even so if they go out of
> business where are the connectors coming from.

The connectors are no longer single sourced as Molex has an equivalent
connector.
http://www.molex.com/cmc_upload/0/000/-17/287/VITA-57CrossRef.pdf
I think that the list price for the LPC is in the neighborhood of
$7-8, does that really qualify as "very expensive".

IMHO, Samtec going out of business is extremely low.

> (6) The currently available FMC modules are many times the price of a
> potential Spartan-6 board especially a starter kit Spartan-6.

Modules will be priced at the level that the market will bear.

The manufacturing cost between an FMC and a propiertary interface
board will not be signficiantly different. If the non-FMC connector
was a $0 cost, then the potential difference in cost is in the range
of $7-8 as the PCB cost and component BOM would be the same.

> (7) There may be IP or licensing issues as a result of the way the
> spec is controlled and owned.

It is an industry standard created under the auspices of VITA and
approved by ANSI.  Everyone involved in this were aware that they had
to notify the commitee of any patent issues and were giving the proper
time to make any disclosures as required by VITA and ANSI
regulations.  This is a very basic specification without a lot of
overhead, most of it is all about the form factor and pin function
locations to ensure compatability between cards.

>  That all said the attraction of common standard is a nice idea. I'm
> just not sure of the practical and cost aspects of it as FMC currently
> appears. There are so many connector standards that could have been
> either reused or just used as is without a totally new standard. One
> of my personal favorites is the PC104 connectors that we allready use
> both in normal mode but also in custom fashions for some of our
> products. We also do that just by FPGA configuration and that
> selection doesn't affect the hardware aspects of our boards.
>
> I think we will adopt FMC on our high end Spartan-6 boards and maybe
> have an adaptor available for our low end. We are looking at the
> practicality of that. Our Virtex-6 boards may have this as standard
> but we debating that. We will also
>
> John Adair
> Enterpoint Ltd.
>

Ed McGettigan
--
Xilinx Inc.

Article: 142476
Subject: Re: Spartan-6 Boards - Your Wish List
From: DJ Delorie <dj@delorie.com>
Date: 12 Aug 2009 12:11:02 -0400
Links: << >>  << T >>  << A >>

Frank Buss <fb@frank-buss.de> writes:
> This would be a lifetime project for most students. I think starting with
> low-level gates is a good idea.

Keep in mind the original question - what should a Spartan-6 board be?
I think most of the people getting such an eval board would want
something that pushed the envelope, not something trivial.

Besides, students can always add a low-level gate as a peripheral ;-)

Article: 142477
Subject: Re: Spartan-6 Boards - Your Wish List
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 12 Aug 2009 17:01:15 GMT
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> wrote:

>DJ Delorie wrote:
>
>> Or better, have it ship pre-programmed to be a standalone web browser
>> - softcpu; drivers for vga, keyboard, mouse, ethernet; mini-OS,
>> browser.  Plug everything in and go, then learn how to do it yourself.
>
>This would be a lifetime project for most students. I think starting with
>low-level gates is a good idea. First with real ones, like 7400 DIL. Then
>maybe with schematics editor and FPGAs, because it is much easier to build
>with the mouse than with wires, but the result, testing in real hardware,
>is the same. Finally some simple programs in VHDL. There are always some
>students who want to implement a web browser after this :-)

I think schematics entry is the worse thing to do when introducing
someone to an FPGA. Better to learn VHDL and look at the schematic
based on the synthesized result.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Article: 142478
Subject: Re: Spartan-6 Boards - Your Wish List
From: John Adair <g1@enterpoint.co.uk>
Date: Wed, 12 Aug 2009 10:12:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Ed

Even if the FMC connectors hit $7-8 that still a major hit when you
sell modules in the area of $20-40 as many of our smaller modules are.
As it happens we were formally quoted several times that number for
the LPC FMC procluding anything other than mid to high range module
products.

If we get into partial I/O variants on this spec is that not going to
defeat the purpose. I can just imagine the number of calls our support
line will get if we have a partial I/O implementation on a board. Even
if you have a FAQ saying so the number of people that will not see or
understand the implications will be large.

Out of interest do have some example pricing and types of module
Xilinx will sell?

John Adair
Enterpoint Ltd.

On 12 Aug, 16:50, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Aug 10, 12:36=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > We have been looking at the FMC standard but it does have a pile of
> > problems for us and our potential customers. This specification was
> > written by a group of people all from companies, in the same market
> > sectors, and with a very limited vison as a result. Problems as I see
> > it:
>
> > (1) The specification costs a lot to buy and will limit widespread
> > adoption and potential customer base.
>
> The VITA-57.1 specification cost is $75 and is only needed by a board
> designer. Having a uniform standard will allow for for wider
> collection of FMC modules that can be used on a wider set of boards
> for increase adoption.
>
> > (2) The format is very small even on the bigger version.
>
> The LPC (Low Pin Count) version has 68 IOs, 2 Clock Pairs, and 1 MGT
> TX/RX + REFCLK. =A0The HPC (High Pin Count) version has 160 IOs, 4 Clock
> Pairs and 10 MGT TX/RX and 2 REFCLKs. =A0Small is in the eye of the
> beholder. =A0If you need more then you can move into a double wide
> configuration.
>
> > (3) A lot of on-module regulation will be needed further limiting what
> > else can be done on the module.
>
> I haven't put any voltage regulation on any of the FMC modules that
> we've designed so far, but I will on some that are coming up. The CC
> (Carrier Card) provides 12V, 3.3V and VADJ (0-3.3V) and the FMC can
> provide one voltage back to the CC (VIO_B). =A0For most FMC this is
> enough, but if you need to a 5V rail then you will need to convert the
> 12V to 5V.
>
> Note: For Xilinx CC, we are fixing the VADJ supply to 2.5V to be
> compatible for both our Virtex-6 and Spartan-6 families IO standards.
>
> > (4) On small and medium size devices, e.g. most Spartans, it uses up
> > most I/O that we would normally use for our own headers and we can't
> > maintain our support for existing customers.
>
> There is no requirement that you must fill up all of the IOs on the
> LPC or HPC. =A0The only requirement is that you start with the LA_00 to
> enable the highest degree of compatability.
>
> > (5) Connectors are very expensive and single source. I will say Samtec
> > is a very good supplier of connectors but even so if they go out of
> > business where are the connectors coming from.
>
> The connectors are no longer single sourced as Molex has an equivalent
> connector.http://www.molex.com/cmc_upload/0/000/-17/287/VITA-57CrossRef.p=
df
> I think that the list price for the LPC is in the neighborhood of
> $7-8, does that really qualify as "very expensive".
>
> IMHO, Samtec going out of business is extremely low.
>
> > (6) The currently available FMC modules are many times the price of a
> > potential Spartan-6 board especially a starter kit Spartan-6.
>
> Modules will be priced at the level that the market will bear.
>
> The manufacturing cost between an FMC and a propiertary interface
> board will not be signficiantly different. If the non-FMC connector
> was a $0 cost, then the potential difference in cost is in the range
> of $7-8 as the PCB cost and component BOM would be the same.
>
> > (7) There may be IP or licensing issues as a result of the way the
> > spec is controlled and owned.
>
> It is an industry standard created under the auspices of VITA and
> approved by ANSI. =A0Everyone involved in this were aware that they had
> to notify the commitee of any patent issues and were giving the proper
> time to make any disclosures as required by VITA and ANSI
> regulations. =A0This is a very basic specification without a lot of
> overhead, most of it is all about the form factor and pin function
> locations to ensure compatability between cards.
>
>
>
> > =A0That all said the attraction of common standard is a nice idea. I'm
> > just not sure of the practical and cost aspects of it as FMC currently
> > appears. There are so many connector standards that could have been
> > either reused or just used as is without a totally new standard. One
> > of my personal favorites is the PC104 connectors that we allready use
> > both in normal mode but also in custom fashions for some of our
> > products. We also do that just by FPGA configuration and that
> > selection doesn't affect the hardware aspects of our boards.
>
> > I think we will adopt FMC on our high end Spartan-6 boards and maybe
> > have an adaptor available for our low end. We are looking at the
> > practicality of that. Our Virtex-6 boards may have this as standard
> > but we debating that. We will also
>
> > John Adair
> > Enterpoint Ltd.
>
> Ed McGettigan
> --
> Xilinx Inc.


Article: 142479
Subject: Re: Spartan-6 Boards - Your Wish List
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 12 Aug 2009 17:16:38 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rainer Buchty <buchty@atbode100.lrr.in.tum.de> wrote:
< In article <1se3s9w5bxodj.1jbhy6iv9zya3$.dlg@40tude.net>,
< Frank Buss <fb@frank-buss.de> writes:

< |> This would be a lifetime project for most students. I think starting with
< |> low-level gates is a good idea. First with real ones, like 7400 DIL. Then
< |> maybe with schematics editor and FPGAs
 
< I like to object here.
 
< At our university we're teaching VHDL to undergrads and grads; the former
< have no previous knowledge of hardware design. Therefore, they start with 
< simple tasks like blinkenlights and stuff, but then quickly move on to 
< design a VGA picture generator, and finally create their own pong clone, 
< altering the original gameplay by further ideas ranging from auto-player, 
< multi-ball, reverse-gravity etc. (A presentation of this course was recently 
< given at CDNlive2009 in Munich.)

I thought the suggestion was for a frosh level introductory course.  
(Such as I previously, mentioned, a one term lecture course followed
by a one term lab course.)

I don't see anything wrong with VHDL for an upper level undergrad
course, but for a first introduction to digital logic that seems
hard to do.  If someone has never thought about the ideas of digital
logic, of wires connecting gates, starting directly in VHDL doesn't
sound good to me.

My understanding now is that some use simulation only for the
introduction.  That is, you have a graphical user interface where
you move around virtual wires and virtual gates.  You could even
shape the gates into TTL chips and require the user to connect
up Vcc and ground.  Still, I think you miss something skipping
at least one lab with a real TTL chip. 

I suppose I believe you could start an introduction to VHDL 
near the end of the lecture course, and if done carefully the
later lab projects in the one term course could be done in VHDL.  

I definitely agree that upper level undergrad courses could
be entirely in VHDL (which I prefer over schematic entry), but
only if the students understand that the underlying technology
is gates and wires.

-- glen


Article: 142480
Subject: Re: Spartan-6 Boards - Your Wish List
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 12 Aug 2009 17:45:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
DJ Delorie <dj@delorie.com> wrote:
 
< Frank Buss <fb@frank-buss.de> writes:
<> This would be a lifetime project for most students. I think starting with
<> low-level gates is a good idea.
 
< Keep in mind the original question - what should a Spartan-6 board be?
< I think most of the people getting such an eval board would want
< something that pushed the envelope, not something trivial.

I think that is my fault.  There are plenty of boards around that
can be used in upper level undergrad courses.  I was trying to
suggest something for introductory (frosh) and intermediate
undergrad courses.  I believe that part of the market is still
underserved.   I am not against more advanced boards, but it
mgiht be time to also design a simpler board.
 
< Besides, students can always add a low-level gate as a peripheral ;-)

At FCCM95 I was part of a discussion on how to teach digital
logic in the future.  I was figuring that in not so many years
TTL gates would be gone.  It seems that they are still available
for now, though.  Much of the discussion was that FGPA companies
should have free software that beginners could use.  That problem
seems to have been solved.

-- glen

Article: 142481
Subject: Re: System gates: Altera <-> Actel
From: Walter <wsfpga@adinet.com.uy>
Date: Wed, 12 Aug 2009 15:38:13 -0300
Links: << >>  << T >>  << A >>
Nagaraj escribió:
> Dear all,
> 
> I'm looking for the equivalent system gate  figures (like in Actel
> Igloo series) of Altera Cyclone II devices. Specifically, an
> equivalent for the EP2C50 in the Igloo series.
> 
> Any suggestion / link is highly appreciated.
> 
> Nagaraj
> 

In FPGA you must compare resources; never gates.

So think about how many and which resources need to build your design.

Walter

Article: 142482
Subject: V5 GTX and V4 MGT interoperability
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 12 Aug 2009 15:00:33 -0400
Links: << >>  << T >>  << A >>
Does anyone know if there are any reports or appnotes on the subject? I 
found a Xilinx report on GTP-MGT interoperability, but nothing on GTX-MGT.


Thanks,
/Mikhail 



Article: 142483
Subject: Re: Spartan-6 Boards - Your Wish List
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 12 Aug 2009 22:51:45 +0200
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> I think schematics entry is the worse thing to do when introducing
> someone to an FPGA. Better to learn VHDL and look at the schematic
> based on the synthesized result.

That's worse, because understanding the produced schematics of non-trivial
VHDL is really difficult, because it uses unusual gates, like
lookup-elements and it is not layouted nicely like a human would do it.

My suggestion was really for frosh level introductory course. For people
who don't know the hot side of an iron. You should at least do one simple
circuit with real TTL gates, maybe with some scope measuring, bad bouncing
push buttons etc., to learn some of the basics from first hand. As John
Adair wrote: It is difficult to understand the nasty side of the analog
world, if you start with VHDL and something goes wrong.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 142484
Subject: Re: Spartan-6 Boards - Your Wish List
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 12 Aug 2009 23:00:06 +0200
Links: << >>  << T >>  << A >>
Rainer Buchty wrote:

> Agreed, but probably not that low-level as Frank suggested, i.e. trying
> to transform 74xx into VHDL models. Especially as the understanding
> required for those kind of jobs definitely includes understanding of
> the architecture and how things may be mapped onto it.

You are right, maybe the schematics part on the FPGA could be skipped. But
I think it is important to build some simple things with real TTL chips.
After this you can continue with VHDL.

> Regarding the mentioned undergrad course, one goal was getting an idea on
> what it takes to create certain machine setups in hardware; in this very
> case it was meant for preservation, i.e. designing full-system emulators
> where the original software would still run on. The final lab project
> therefore was about a compatible re-creation of an existing arcade machine 
> within an FPGA. Here, the focus was more put on understanding "alien" code,
> extending it, and and making it work within an own design rather than 
> writing anything own stuff as required in the preceding tasks.
> 
> If you're interested, the poster gives a quick overview:
>         http://itec.uka.de/~buchty/pub/2009-cdnlive-poster.pdf
> 
> with the extended abstract being this:
> 	http://itec.uka.de/~buchty/pub/2009-cdnlive.pdf

This sounds like a good course. Learning all at once, implementing a CPU
and coding the programs which runs on the CPU, would be more difficult. If
you have already an architecture and some old assembler code, you can
concentrate on designing a CPU for it.

-- 
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Article: 142485
Subject: Re: Is it possible to use OSERDES and ISERDES primitives internal to
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 12 Aug 2009 17:32:53 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 12, 11:40=A0am, Test01 <cpan...@yahoo.com> wrote:
> On Aug 12, 6:21=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> I am not trying to test the specifics of OSERDES and ISERDES in
> design1. =A0Design1 contans a split transaction serial bus exerciser
> that I need to use to test design2. =A0But design1 uses OSERDES and
> ISERDES primitves to serilize the bit stream of the split transaction
> bus as it was intended for normal I/O application. =A0Here I am trying
> to figure out if I can use design1 as is to test design2. =A0It seems
> that at minimum I need to replace the ISERDES and OSERDES with my own
> serilizer and derserilizer verilog models to keep the low effort
> level. I am trying to avoid designing design1 from scratch in order to

You have three options, listed from worst to best (in my opinion)
1.  Bring the design 1 SERDES outputs out to I/O pins and modify the
board to connect these outputs to the inputs pins of design 2.
2.  Re-read the second and third paragraph of my previous post and
implement that instead.  You do not need to write code for a
serializer or a deserializer in order to implement the combined
function of both.  To do this you don't need to hack up design 1, you
simply need to change the top level I/O of design 1 and design 2 to
have a wider parallel interface and connect them together either with
a bank of flops or a fifo as I suggested previously.  Since this
interface is all internal to the FPGA no I/O pin modifications to the
board are required.
3.  The best option is to simulate the system.  Instantiate design 1
and design 2, connect the I/O appropriately, model other parts on the
PCBA if necessary.  Set up any other stimulus as required, run the
simulation and verify that the design operates properly.  This is the
best and most accurate way of getting your design correct.  Once
skilled in this process it is far more productive than debug on
hardware

Kevin Jennings

Article: 142486
Subject: Can I suppress invoking Block SelectRAMs in virtex5?
From: coredev <coredev@gmail.com>
Date: Wed, 12 Aug 2009 18:59:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear all.

I wrote some HDL code for LUTs.
I tried both sequential and combinational way like

lutout <= 1 when sel = 0 else
             78 when sel = 1 else
             32 when sel = 2 else .......

and

case sel is
when 0 => lutout <= 1;
when 1 => lutout <= 78;
when 2 => lutout <= 32;
.......


In both cases, the synthesis tool (synplify, in my case) invoke Block
SelectRAMs for that LUTs.

synthesis:
@N: FX211 |Packed ROM u1701.lut012[30:23] (8 input, 8 output) to Block
SelectRAM


However, I want to keep them in gate logics since there are limited
numbers of memory blocks,
and I need to use them for other module.

The synthesis tool reports that the design used
>> 256x1 ROMs (ROM256X1): 1107, Block Rams : 288 of 288 (100%)
as a result, the mapping tool reports overmapping error
>>   Number of BlockRAM/FIFO: 369 out of     288  128% (OVERMAPPED)

Since the logic utilization is still around 40%, I think I can use
slices for that LUTs.
Can I force the synthesis tool to do not use Block Rams for that LUTs?

Thanks for reading.


S. Jin

Article: 142487
Subject: Re: algorithm implementation in IC
From: jogging <joggingsong@gmail.com>
Date: Wed, 12 Aug 2009 19:45:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks, Kolja

On Aug 11, 9:24=A0pm, Kolja <ksuli...@googlemail.com> wrote:
> On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote:> =A0In IC desgi=
n, the first step is algorithm
> > design and C model implementation.
>
> I always wondered why anyone would want to model the algorithms in
> C nowadays. There are so many nice modern languages around with
> object orientation, etc.
> Prototyping should be much quicker and less error prone with any of
> these
> compared to C.
I am not a IC design engineer, so not familiar with practice in IC
industry.
I'm only curious the way how the gap between algorithm design and
FPGA implementation is solved.
From wikipedia, it says
ESL design: This step creates the user functional specification. The
user may use a variety of languages and tools to create this
description. Examples include a C/C++ model, SystemC, SystemVerilog
Transaction Level Models, Simulink and MATLAB.

Do you mean MATLAB is used to develop prototype?
What are the most popular languages to develop prototype?

>
> > Do algorithm
> > engineers need to know FPGA implementation details
> > In this step?
>
> I think it is sufficient to have some information on the cost of
> various
> operations, like the number and size of RAMs, Multipliers, FIFOs etc.
> And some informations on the relativ speed of these operations.
>
> Kolja Sulimma

Best Regards
Jogging

Article: 142488
Subject: Re: Peter Alfke
From: luudee <rudolf.usselmann@gmail.com>
Date: Wed, 12 Aug 2009 23:35:21 -0700 (PDT)
Links: << >>  << T >>  << A >>


Just saw this threat ...


Peter, all the best wishes, I hope we will keep seeing you
around and can continue to count on your feedback where it
matters.

Good Luck,
rudi

Article: 142489
Subject: Re: Can I suppress invoking Block SelectRAMs in virtex5?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 12 Aug 2009 23:36:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 13, 4:59=A0am, coredev <core...@gmail.com> wrote:
> Dear all.
>
> I wrote some HDL code for LUTs.
> I tried both sequential and combinational way like
>
> lutout <=3D 1 when sel =3D 0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A078 when sel =3D 1 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A032 when sel =3D 2 else .......
>
> and
>
> case sel is
> when 0 =3D> lutout <=3D 1;
> when 1 =3D> lutout <=3D 78;
> when 2 =3D> lutout <=3D 32;
> .......
>
> In both cases, the synthesis tool (synplify, in my case) invoke Block
> SelectRAMs for that LUTs.
>
> synthesis:
> @N: FX211 |Packed ROM u1701.lut012[30:23] (8 input, 8 output) to Block
> SelectRAM
>
> However, I want to keep them in gate logics since there are limited
> numbers of memory blocks,
> and I need to use them for other module.
>
> The synthesis tool reports that the design used>> 256x1 ROMs (ROM256X1): =
1107, Block Rams : 288 of 288 (100%)
>
> as a result, the mapping tool reports overmapping error
>
> >> =A0 Number of BlockRAM/FIFO: 369 out of =A0 =A0 288 =A0128% (OVERMAPPE=
D)
>
> Since the logic utilization is still around 40%, I think I can use
> slices for that LUTs.
> Can I force the synthesis tool to do not use Block Rams for that LUTs?
>
> Thanks for reading.
>
> S. Jin

look synthesis attributes, you can disable the block ram from some
block/signal entity

our client just had similar problem where they needed small ROM to be
implemented in non block RAM

they had initially small problem, they prohibited block RAM, but not
block ROM, but after changing
constraint to not use block rom it worked well

Antti



Article: 142490
Subject: Re: algorithm implementation in IC
From: "HT-Lab" <hans64@ht-lab.com>
Date: Thu, 13 Aug 2009 08:17:00 +0100
Links: << >>  << T >>  << A >>

"jogging" <joggingsong@gmail.com> wrote in message 
news:b67735ce-69c4-4e5a-81d0-9afaa25f54e7@v20g2000yqm.googlegroups.com...
Thanks, Kolja

On Aug 11, 9:24 pm, Kolja <ksuli...@googlemail.com> wrote:
> On 11 Aug., 11:01, jogging <joggings...@gmail.com> wrote:> In IC desgin, the 
> first step is algorithm
> > design and C model implementation.
>
> I always wondered why anyone would want to model the algorithms in
> C nowadays. There are so many nice modern languages around with
> object orientation, etc.
> Prototyping should be much quicker and less error prone with any of
> these
> compared to C.
>I am not a IC design engineer, so not familiar with practice in IC
>industry.
>I'm only curious the way how the gap between algorithm design and
>FPGA implementation is solved.
>From wikipedia, it says
>ESL design: This step creates the user functional specification. The
>user may use a variety of languages and tools to create this
>description. Examples include a C/C++ model, SystemC, SystemVerilog
>Transaction Level Models, Simulink and MATLAB.

>Do you mean MATLAB is used to develop prototype?

yes, Matlab is quite popular for algorithmic model development. You can then 
translate your m-code to C and use it in your virtual system and/or put a 
SystemC wrapper around it and use it in your RTL simulation.

>What are the most popular languages to develop prototype?

I believe C/C++ are still the most widely used prototype languages followed by 
SystemVerilog/SystemC

Hans
www.ht-lab.com


>
> > Do algorithm
> > engineers need to know FPGA implementation details
> > In this step?
>
> I think it is sufficient to have some information on the cost of
> various
> operations, like the number and size of RAMs, Multipliers, FIFOs etc.
> And some informations on the relativ speed of these operations.
>
> Kolja Sulimma

Best Regards
Jogging 



Article: 142491
Subject: Re: Partial Reconfiguration - Pin access from within the module
From: Fabian Schuh <Fabian.Schuh@soft-gate.de>
Date: Thu, 13 Aug 2009 10:23:48 +0200
Links: << >>  << T >>  << A >>
Fabian Schuh schrieb:
> Hello group,
> 
> I am trying to acces some IOB from within a partial reconfigurable 
> module (prm).
> 
> The arch would look like this:
> 
>                       /- IOB
>                       |
> |---------------------|----|
> ||--------------| |---|---||
> ||              | |       ||
> || static part  | |  PRM  ||
> ||              |-|       ||
> ||              |-|       ||
> ||              |-|       ||
> ||              |-|       ||
> ||              | |       ||
> ||              | |       ||
> ||              | |       ||
> ||--------------| |-------||
> |--------------------------|
> 
> Between both modules, there are the busmacros.
> Those are working great. Anyway, the IOB located above the prm must be 
> connected to the prm. No busmacros. I tried so by connecting the IOB 
> (named debug_io(21)) within the toplevel design.
> ++++++++++++++++++++++++
> mod_can_wrapper: mod_can
> port map (
> ...
>     id => debug_io(21),
> ...
>     );
> ++++++++++++++++++++++++
> 
> The problem appears while running 'par':
> ++++++++++++++++++++++++
> ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part of 
> a slice macro.
>        Nets crossing region boundaries must be part of a slice macro
> ++++++++++++++++++++++++
> I remeber setting the -iobuf option of 'xst' to no, so the module itself 
> does not add ibufs to the interface signals.
> 
> 
> My question is: How can I access IOBs from within the module?
> 
> Thanks for your help
> 
> Sincerely
>     -- Fabian Schuh

Hi there,

found the relevant part in "Xilinx Development System Reference Guide" 
<www.xilinx.com/itp/xilinx8/books/docs/dev/dev.pdf>

It says on page 110:
+++++++++++++++++++++++++++++
External I/Os in a Module
It is recommended that you declare external I/Os in the top-level 
design. However, you
can include external I/Os in a module without modifying the top-level 
code. This may be
useful if you want to add a temporary external I/O in the module for 
simulation. To do
this, explicitly instantiate IBUF/IBUFG/BUFGP and OBUF connections. 
Following are
examples of code.
Note: Do not directly connect these I/Os to module ports.
+++++++++++++++++++++++++++++

Greetz
	-- Fabian

Article: 142492
Subject: Re: Partial Reconfiguration - Pin access from within the module
From: Fabian Schuh <Fabian.Schuh@soft-gate.de>
Date: Thu, 13 Aug 2009 10:27:31 +0200
Links: << >>  << T >>  << A >>
Fabian Schuh schrieb:
> Fabian Schuh schrieb:
>> Hello group,
>>
>> I am trying to acces some IOB from within a partial reconfigurable 
>> module (prm).
>>
>> The arch would look like this:
>>
>>                       /- IOB
>>                       |
>> |---------------------|----|
>> ||--------------| |---|---||
>> ||              | |       ||
>> || static part  | |  PRM  ||
>> ||              |-|       ||
>> ||              |-|       ||
>> ||              |-|       ||
>> ||              |-|       ||
>> ||              | |       ||
>> ||              | |       ||
>> ||              | |       ||
>> ||--------------| |-------||
>> |--------------------------|
>>
>> Between both modules, there are the busmacros.
>> Those are working great. Anyway, the IOB located above the prm must be 
>> connected to the prm. No busmacros. I tried so by connecting the IOB 
>> (named debug_io(21)) within the toplevel design.
>> ++++++++++++++++++++++++
>> mod_can_wrapper: mod_can
>> port map (
>> ...
>>     id => debug_io(21),
>> ...
>>     );
>> ++++++++++++++++++++++++
>>
>> The problem appears while running 'par':
>> ++++++++++++++++++++++++
>> ERROR: Net debug_io_21_IBUF crosses a region boundary and is not part 
>> of a slice macro.
>>        Nets crossing region boundaries must be part of a slice macro
>> ++++++++++++++++++++++++
>> I remeber setting the -iobuf option of 'xst' to no, so the module 
>> itself does not add ibufs to the interface signals.
>>
>>
>> My question is: How can I access IOBs from within the module?
>>
>> Thanks for your help
>>
>> Sincerely
>>     -- Fabian Schuh
> 
> Hi there,
> 
> found the relevant part in "Xilinx Development System Reference Guide" 
> <www.xilinx.com/itp/xilinx8/books/docs/dev/dev.pdf>
> 
> It says on page 110:
> +++++++++++++++++++++++++++++
> External I/Os in a Module
> It is recommended that you declare external I/Os in the top-level 
> design. However, you
> can include external I/Os in a module without modifying the top-level 
> code. This may be
> useful if you want to add a temporary external I/O in the module for 
> simulation. To do
> this, explicitly instantiate IBUF/IBUFG/BUFGP and OBUF connections. 
> Following are
> examples of code.
> Note: Do not directly connect these I/Os to module ports.
> +++++++++++++++++++++++++++++
> 
> Greetz
>     -- Fabian

Hi again,

The verilog example description is more precise:
++++++++++++++++++++
In the following example, the module has two external inputs 
(IPAD_MODA_CLK and
IPAD_MODA_DATA) and one external output (OPAD_MODA_OUT). These external
I/Os, IBUF, OBUF, and BUFGP are instantiated.
The lower-level port declaration is different from the top-level 
declaration of module_a.
Lower-level module_a has three additional ports. With Modular Design, 
NGDBuild
ignores this port mismatch and uses module_a.edf to describe module_a. These
I/Os will be present in the design and available for simulation.
++++++++++++++++++++

Greetz
	-- Fabian

Article: 142493
Subject: why synthesize not work?
From: braver <tzeng@andanetworks.com>
Date: Thu, 13 Aug 2009 02:19:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
I create a embed processor under ISE top module .
After I instantiate it , I can 't synthesize it .
In fact , synthesizer don't run and don't give any error report.
I use XST synthesizer.


I suspect I make some mistake in my program.
So I output/input all port of this processor to external pin.
Now synthesizer work.
But even I don't instantiate one output port of this processor.
The synthesizer don't work.


In the past , I can leave the ouput port of sub module as blank , and
no problem happen .
Can some one give me some advice.

Article: 142494
Subject: Simulating Xilinx EDK Systems
From: Simon Heinzle <simon.heinzle@gmail.com>
Date: Thu, 13 Aug 2009 04:18:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I just recently tried out the nice Xilinx EDK, mainly because of the
MicroBlaze processor. With the tools provided from Xilinx, it seems
that the only way to simulate a system containing peripherals,
processors, FSLs etc is to use HDL simulation. Unfortuntaly, HDL
simulation is slow.

I would rather like to have a software simulation for EDK systems. I
understand that the deprecated Virtual Platform offered such a thing.
Benefits of a software simulation I would expect are faster
prototyping (evaluating different systems fast), and easier testing of
software applications for such systems (in case no FPGA is available
just right now, or to benchmark those systems better). An ideal system
would be cycle-accurate, and good system would be timing-approximate,
a still usable system would just provide correct results from the
tested software.

One option I saw was to model all the used EDK components and
proprietary IP with e.g. SystemC, similar to SoCLib (https://
www.soclib.fr/trac/dev/wiki).

Another option I just found is similar to the one described in the
paper "A Multi-MicroBlaze Based SOC System: From SystemC Modeling to
FPGA Prototyping" by S. Xu and H. Pollitt-Smith. They developed models
for BRAM,  OBP, etc and used a wrapper around the MicroBlaze ISS that
communicates with their SystemC model.

Does anybody of you have good ideas how such a system could be
realized, or is aware of any tools (even commercial) that I have not
found yet?

Thank you a lot in advance!


I would like to evaluate different systems fast, and to test software
applications for such a system in a software simulation. In the best
case, the system would


To evaluate systems and to provide a tool to test applications for
such a system I would like

Article: 142495
Subject: JTAGkey-Tiny with Altera/Xilinx FPGA?
From: "sdaau" <sd@imi.aau.dk>
Date: Thu, 13 Aug 2009 07:03:02 -0500
Links: << >>  << T >>  << A >>
Hi, 

I am looking into starting with FPGA's, and as I am looking for the
cheapest solution to start programming, I'm thinking of getting the
JTAGkey-Tiny:

http://www.amontec.com/jtagkey-tiny.shtml

My question is, if it is possible to use it in the similar sense that the
big JTAGkey is advertised: "upload Altera, Atmel, Cypress, Lattice, Xilinx
FPGA / CPLD with your SVF files." (http://www.amontec.com/jtagkey.shtml). I
am aware that most likely not all chips will be supported, and having to
make own connections and a host of other factors will increase the
probability of errors - but if it is in principle possible, I'd be willing
to try it. 

If it is possible to program (some of) these chips with JTAGkey-Tiny, I
see that the JTAGkey-Tiny has a 20 pin header, whereas:

"Xilinx and Altera FPGAs use six and 10 pins respectively for their JTAG
interfaces. The Xilinx one just uses Vcc, Gnd, TCK, TDO, TDI and TMS."
(http://www.xlinkers.org/forum/viewtopic.php?f=7&t=104)

Is there information available on how to pull these 6(10) wire interface
from the 20 pin header? If anyone has had experience with this, it would be
great to see some comments ! :) 

Cheers !



Article: 142496
Subject: Re: JTAGkey-Tiny with Altera/Xilinx FPGA?
From: Jon <jon@beniston.com>
Date: Thu, 13 Aug 2009 05:23:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
Have a look here: http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,395&Cat=5&gclid=CNOuiNHPoJwCFdYB4wodumJvew
for some cheap JTAG cables that might already have the correct
connector for the board you want to use.

Jon

Article: 142497
Subject: Re: JTAGkey-Tiny with Altera/Xilinx FPGA?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Thu, 13 Aug 2009 06:05:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 13, 3:03=A0pm, "sdaau" <s...@imi.aau.dk> wrote:
> Hi,
>
> I am looking into starting with FPGA's, and as I am looking for the
> cheapest solution to start programming, I'm thinking of getting the
> JTAGkey-Tiny:
>
> http://www.amontec.com/jtagkey-tiny.shtml
>
> My question is, if it is possible to use it in the similar sense that the
> big JTAGkey is advertised: "upload Altera, Atmel, Cypress, Lattice, Xilin=
x
> FPGA / CPLD with your SVF files." (http://www.amontec.com/jtagkey.shtml).=
 I
> am aware that most likely not all chips will be supported, and having to
> make own connections and a host of other factors will increase the
> probability of errors - but if it is in principle possible, I'd be willin=
g
> to try it.
>
> If it is possible to program (some of) these chips with JTAGkey-Tiny, I
> see that the JTAGkey-Tiny has a 20 pin header, whereas:
>
> "Xilinx and Altera FPGAs use six and 10 pins respectively for their JTAG
> interfaces. The Xilinx one just uses Vcc, Gnd, TCK, TDO, TDI and TMS."
> (http://www.xlinkers.org/forum/viewtopic.php?f=3D7&t=3D104)
>
> Is there information available on how to pull these 6(10) wire interface
> from the 20 pin header? If anyone has had experience with this, it would =
be
> great to see some comments ! :)
>
> Cheers !

sure its possible, just the connector is ARM standard 20 pin
so you need to remap the jtag lines.

but it works very nicely, you can program pretty much any
JTAG devices (FPGA's..too!)

Antti





Article: 142498
Subject: Re: V5 GTX and V4 MGT interoperability
From: austin <austin@xilinx.com>
Date: Thu, 13 Aug 2009 10:12:58 -0700 (PDT)
Links: << >>  << T >>  << A >>
Mikhail,

They are both designed to standards, so they are compatible if each is
using the same standard (same rate, and data format).

Of one note, check the common mode voltages for the standard:  in some
cases AC coupling is required, (although I think this is only true for
the lower voltage GTX to higher supply voltage GTP).

Article: 142499
Subject: Re: why synthesize not work?
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 13 Aug 2009 10:36:48 -0700
Links: << >>  << T >>  << A >>
braver wrote:

> In the past , I can leave the ouput port of sub module as blank , and
> no problem happen .
> Can some one give me some advice.

Synthesis works from port to port on the top module/entity.
No ports, no gates.

      -- Mike Treseler



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