Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
On Wed, 22 Jul 2009 04:50:22 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >On Jul 22, 5:09 am, Mike Harrison <m...@whitewing.co.uk> wrote: >> On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wrote: >> >Unfortunately, the generate statement only allows conditionally >> >including concurrent statements. >> >> so does that mean that, for example, you couldn't use it to conditionally exclude particular case >> branches in a case structure? >> >Generate statements would not be used to conditionally exclude >particular case branches, they can only exclude concurrent statements >or instantiation of entities. > >I don't see much utility you would get from excluding particular case >branches at all. The case conditions by definition must be >- mutually exclusive >- cover all cases > >Excluding a particular branch condition with an #ifdef would either >violate the 'cover all cases' rule or force that particular branch to >now follow the 'when others' default path. I haven't run across a >situation where I've ever wanted to code something like that. In any >case, you can still use the 'if...then' inside the case branch to >branch around the code you would like to exclude. It's roughly the >same amount of typing so it shouldn't be any extra work one way or the >other. The situation that comes to mind is a state machine where some of the cases handle debug functionality, or servicing peripheral devices which are not present in some variants Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle' state. >- Pin numbers on physical parts never have a need to 'move'. >A given >board will have a given part which will have pins connected to >specific other pins on that board. There will not be any reason to >vary these pin numbers for a given design while also maintaining the >old pin numbers. Yes they will - I have a prototype running on a devboard with a 484BGA with tons of extra IOs for debug outputs, and the production board will be the same device in 144QFP. It is also quite plausible that changes in production boards need pin allocations to change for layout reasons, as the board is only 4 layer.. I would ideally like to have a single project and a simple way to flip it between 'devboard' and 'production board' mode, but it seems that this will be far from being as straightforward as it would be for a similarly 'varianted' microcontroller project.Article: 142026
On Wed, 22 Jul 2009 12:06:43 +0000 (UTC), Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: >Martin Thompson <martin.j.thompson@trw.com> wrote: >> jleslie48 <jon@jonathanleslie.com> writes: > >> > Sorry to start from scratch yet again, but I don't know where to >> > begin. >> > >> > In the past I've had log file info dump out onto a UART as >> > necessary. The UART is slow, and requires an additional device to >> > capture the datastream. >> > > >> How fast do you need? FTDIs UART-USB (TTL-232R-3V3) cable will go @ >> 3Mbps IIRC. It's an extra cable, hardly a device though, unless you >> count the PC as well? > >If you go with the FT245 or FT2232 in 245 mode, rate can even be higher, at >the cost of more pins. Requirements on the PC side are the same. And the FT2232H/4232H devices will go even faster...Article: 142027
I installed the full-up Xilinx ISE 11.x tools on a spare machine so I could give it a test-drive. (We have a site license.) I checked out a fresh copy of the trunk of a working, shipping design that was created with ISE 10.1.3. I used 10.1's rather-nifty "Source Control | Export" feature to boil the binary ISE project file down to a source-control-friendly tcl script, and as such the only parts of the project that are in the repository are the VHDL sources, the UCF and the three tcl scripts created by the Export. With 10.1, this is sufficient to completely recreate the ISE project file in all of its bloated glory. Then I launched ISE 11. I clicked on the "Project | Source Control | Import ..." menu item, hoping to import the project. Instead of happiness, I got a dialog box saying that this feature was shitcanned, and that I should import the project in the previous version to create the .ISE project file, and then open that project file in 11.x. The dialog also said something about using the shell to expand the project file, but I couldn't figure out how to do this. So, Xilinx: thanks a whole lot for taking one of the few actually useful features of the Project Navigator and throwing it -- and your customers who were foolish enough to rely on it -- under the bus. There's really no reason for this feature to be removed, except that you wanted to prove how much you hate your customers (as if moving to FlexLM wasn't enough). I opened a WebCase, which I suspect will be ignored like every other WebCase. -aArticle: 142028
maverick wrote:
> Thanks alot all for helping me out with your valuable ideas and
> experiences. Actually, I dont see a timing problem there.
Have you run static timing?
Synchronized all inputs?
> Had it been
> a timing problem, it should have given me the same problem on the
> first FPGA board which is identical.
The asynchronous delays are not identical from board to board
or from synthesis to synthesis.
-- Mike Treseler
Article: 142029
Mike Harrison wrote:
> I would ideally like to have a single project and a simple way to flip it between 'devboard' and
> 'production board' mode, but it seems that this will be far from being as straightforward as it
> would be for a similarly 'varianted' microcontroller project.
Any way I flip it, some file must be edited.
-- Mike Treseler
Article: 142030
I used a Virtex-II XC2V1000 some time ago. The datasheet says the
capacity is ~1M system gates
with 5,120 slices.
Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has
10,752 slices but no longer
gives the equivalent "system gates" capacity.
Question: how do I compare the capcity of XC4VLX25 to the XC2V1000 ?
is the capacity of XC4VLX25 =2X the capacity of
XC2V1000,
since there are 2X the number of slices?
I don't need the DSP logic, just need to compare system
gates.
Note, the developement board I want to buy comes with
the XC4VLX25,
and I need to make sure this has at least the gate
capacity of the older XC2C1000
-steve
Article: 142031Larry The Darnaw1 is an option particularly if you want more I/O. The only thing on Darnaw1 the I/O does not have 5V protection like the Craignell/Drigmorn family. Cost wise the Darnaw1 is also more expensive. The PGA array does cost a reasonable amout in the manufacture process. If you are going to the trouble of a carrier board consider the Craignell2 if it has enough I/O for your needs. The Ethernet Phy module is baed on a DP83848. There isn't much on the website about this product and I will see if I can get that fixed. Don't get confused by the Etheret Controller mdule whih is a different product. The clock is expected to supplied by the host board/FPGA. Incidentially on Craignell2 it does actually have a 25MHz oscillator although some documentation suggests 40Mhz. In reality the Darnaw1 regulators don't normally get very hot. Typical designs will drop about 1.5W in the dual package. It's mainly a legal statement but of course there are exceptions and they may get hot in some circumstances e.g. fault or shorted. Darnaw1 is 67.5mm x 67.5mm (2.66 inches x 2.66 inches). Note the PGA is offset to one corner. Incidentially the new product that's coming uses switching regulators so heat will be less of a issue. I'll be at DAC next week if you happen to be there. I'll be there with the new product Merrick1 hopefully soothing it's 101 FPGAs into some kind of action. John Adair Enterpoint Ltd. On 22 July, 03:52, "AstroLad" <Astro...@cox.net> wrote: > John, > > The size is probably manageable, but we don't need the extra features. > > How about this possibility: Darnaw 1 with the non-PCI Ethernet module. We > have to make a carrier board for our circuitry anyway. So we put the Darnaw > on one side, the Ethernet on the opposite side and our circuits wherever > they will fit. That has the appeal of getting only what we need to keep the > cost and power down. > > A few more questions if you don't mind. I could not find answers on your > web site. > > 1. Size of the Darnaw. I estimate about 2.8" square from the picture. > 2. Does the Ethernet module have a PHY or a MAC/PHY? What device? > 3. Does the Ethernet module have an oscillator? I can't tell from the > Xilinx documentation if the 1200E DLLs can internally handle 800MHz (25MHz > = (32MHz * 25) / 32). I guess we could put a separate oscillator on our > board if we have to. > 4. The Darnaw manual says that the regulators get very hot. Will they > survive being enclosed in a small volume, say 4"x3"x2", with no airflow? > > Thanks for your patience. > > Larry > > > > > > >Larry > > >The size of the board is about 67.5mm x 96.5mm. It is a lot bigger > >than the related Craignell2 because it has expansion headers, usb, > >display, accelerometer that make it bigger. > > >The board has our standard dil header arrangement that you can see on > >several of our boards and we do have a phy module for these headers so > >you can probably have the configuration you want asumig the size meets > >the requirement. > > >John Adair > >Enterpoint Ltd. > > >On 18 July, 14:25, "AstroLad" <Astro...@cox.net> wrote: > >> John, > > >> Can you give me a few details? Will the new board be the same, or > roughly > >> the the same size as the Craignell2? What about Ethernet? We want a > 10/100 > >> PHY (best), or MAC/PHY. The reason the PHY is best for us is that I > already > >> developed a simplified MAC tuned to our processor core. It doesn't > take > >> much space and not much support code. > > >> Thanks, > > >> Larry Dingle > > >> >We have a product coming shortly based on our Craignell2 but a > >> >development board format that might offer an alternative. If you have > >> >a few weeks then wait and see if suits your application. > > >> >John Adair > >> >Enterpoint Ltd. > > >> >On Jul 6, 2:19=A0pm, "AstroLad" <Astro...@cox.net> wrote: > >> >> Does anyone know of anything similar to the Suzaku SZ030/SZ130? > It's > >> just > >> >> about a perfect fit for a short production run product I'm helping > a > >> frie= > >> >nd > >> >> with. Perfect that is except the price. What we need is an FPGA as > good > >> o= > >> >r > >> >> better than a XC3S1000, 1MB or more of RAM (SRAM or SDRAM) and > 100MB > >> >> Ethernet. It does not absolutely have to be a Spartan. An Altera > >> Cyclone = > >> >of > >> >> some flavor would do if the price were right. We already have a lot > of > >> >> development done using Digilent Spartan boards. We don't need the > >> >> Microblaze as we have a CPU from OpenCores that is adequate.- Hide > quoted text - > > >> - Show quoted text -- Hide quoted text - > > - Show quoted text -Article: 142032
Hello, The capacity of the device is entirely dependent on your design, not "system gates." Take your design and synthesize it on a XC4VLX25 to see if it will fit. I would be very surprised if it doesn't, but that's the way you can tell. "System gates" are an entirely marketing phenomenon, not an engineering metric. - Nathan On Jul 22, 12:32=A0pm, stevem <steve.martind...@gmail.com> wrote: > I used a Virtex-II =A0XC2V1000 some time ago. The datasheet says the > capacity is ~1M system gates > with 5,120 slices. > > Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has > 10,752 slices but no longer > gives the equivalent "system gates" capacity. > > Question: how do I compare =A0the capcity of XC4VLX25 to the XC2V1000 ? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the capacity of XC4VLX25 =A0=3D2X the c= apacity of > XC2V1000, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0since there are 2X the number of slices? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't need the DSP logic, just need to c= ompare system > gates. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, the developement board I want to buy co= mes with > the XC4VLX25, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 and I need to make sure this has at least the= gate > capacity of the older XC2C1000 > > =A0 =A0 -steveArticle: 142033
On Jul 22, 1:11 pm, Mike Harrison <m...@whitewing.co.uk> wrote:
> On Wed, 22 Jul 2009 04:50:22 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> wrote:
> >On Jul 22, 5:09 am, Mike Harrison <m...@whitewing.co.uk> wrote:
> >> On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wrote:
> >I don't see much utility you would get from excluding particular case
> >branches at all. The case conditions by definition must be
> >- mutually exclusive
> >- cover all cases
>
> >Excluding a particular branch condition with an #ifdef would either
> >violate the 'cover all cases' rule or force that particular branch to
> >now follow the 'when others' default path. I haven't run across a
> >situation where I've ever wanted to code something like that. In any
> >case, you can still use the 'if...then' inside the case branch to
> >branch around the code you would like to exclude. It's roughly the
> >same amount of typing so it shouldn't be any extra work one way or the
> >other.
>
> The situation that comes to mind is a state machine where some of the cases handle debug
> functionality,
OK, so what is inherently better about this...
case xyz is
when Blah =>
#ifdef DEBUG
-- Put your debug code here
#end if
...etc...
end case;
Compared to this...
case xyz is
when Blah =>
if DEBUG
-- Put your debug code here
end if;
...etc...
end case;
where 'DEBUG' is some boolean.
If instead you mean being able to put the #ifdef outside the branch
like this...
case xyz is
#ifdef DEBUG
when Blah =>
-- Put your debug code here
#end if
...etc...
end case;
Then, OK the #ifdef lets you make this edit quicker. But that means
either that you also have to edit the type definition to remove the
'Blah' state or leave it in and let the 'when others' pick it up and
hope that this state bit synthesizes away so it doesn't cost you. The
other way to code this would be...
if (DEBUG and (xyz = Blah) then
-- Put debug code here
else
case xyz is
...
end case;
end if;
I don't see any inherent advantage in the situation you alluded to
where #ifdef-ing the entire 'when xxx' statement versus using other
coding styles...but you and others might disagree...that's fine.
> or servicing peripheral devices which are not present in some variants
> Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle'
> state.
>
If the peripherals are not there in some variants, then simply not
connecting any of the output signals from the entity that produces the
unneeded signals to any of the top level entity outputs is
sufficient. The synthesis tool will not produce any logic to
implement anything that doesn't affect an output pin.
> >- Pin numbers on physical parts never have a need to 'move'.
> >A given
> >board will have a given part which will have pins connected to
> >specific other pins on that board. There will not be any reason to
> >vary these pin numbers for a given design while also maintaining the
> >old pin numbers.
>
> Yes they will - I have a prototype running on a devboard with a 484BGA with tons of extra IOs for
> debug outputs, and the production board will be the same device in 144QFP.
> It is also quite plausible that changes in production boards need pin allocations to change for
> layout reasons, as the board is only 4 layer..
>
That would be an example of two different boards with two different
parts...as I mentioned previously either of these two conditions is
not an example of ever having to 'move' a signal, it is an example of
two different designs.
Your situation is describing two different boards that use two
different parts that are intended to implement (I'm guessing) the
exact same function (i.e. the same VHDL logic description). Taking
that as the premise, you've got two unique designs that you need to
maintain. The differences between those two design being all related
to physical part differences and not (or possibly not) any logic
differences. The synthesis process consists of running a tool that
pulls together the following types of information in order to
complete:
- Target device
- Device migration constraints
- Logic description (i.e. the VHDL)
- Pinout constraints
- Timing constraints
- I/O Drive constraints
- Voltage standard constraints
The logic description is the only thing that should be entered into
the VHDL files. All of the other constraints are inherently device
specific and therefore needed by the synthesis tool (i.e ISPLever),
none of them belong in the VHDL files. They belong in whatever files
the synthesis tool stores them in.
The fact that you have two different end targets simply means that you
have two different project files.
> I would ideally like to have a single project and a simple way to flip it between 'devboard' and
> 'production board' mode, but it seems that this will be far from being as straightforward as it
> would be for a similarly 'varianted' microcontroller project.- Hide quoted text -
>
If the differences are only in the logic, then this can be handled
pretty simply with a single project file. Synthesis tools allow you
to set top level generics so to 'switch' between debug and release you
would write your code to work with a generic called 'DEBUG' and then
use the synthesis tool to set it however you want it today. When you
get outside of logic and into the other constraints that I mentioned
previously, what you really need then is something different from the
synthesis tool, not the VHDL language.
I kind of get the impression though that you'd like to treat all of
these variants as if they were somehow really 'the same' in some
sense. But in reality, each environment that a design is in (i.e. the
devboard or the production board) will have their own quirks and
require their own individual debug efforts and you'll likely find the
designs will need to be archived properly so having separate project
files and treating them like separate designs (which they really are)
is a long term better approach.
Bottom line is, it's just as easy to open a project file from 'File-
>Open...' as it is to otherwise change some setting from 'Debug' to
'Release'.
Kevin Jennings
Article: 142034On Jul 22, 4:14=A0pm, Nathan Bialke <nat...@bialke.com> wrote: > Hello, > > The capacity of the device is entirely dependent on your design, not > "system gates." Take your design and synthesize it on a XC4VLX25 to > see if it will fit. I would be very surprised if it doesn't, but > that's the way you can tell. "System gates" are an entirely marketing > phenomenon, not an engineering metric. > > - Nathan > > On Jul 22, 12:32=A0pm, stevem <steve.martind...@gmail.com> wrote: > > > I used a Virtex-II =A0XC2V1000 some time ago. The datasheet says the > > capacity is ~1M system gates > > with 5,120 slices. > > > Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has > > 10,752 slices but no longer > > gives the equivalent "system gates" capacity. > > > Question: how do I compare =A0the capcity of XC4VLX25 to the XC2V1000 ? > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the capacity of XC4VLX25 =A0=3D2X the= capacity of > > XC2V1000, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0since there are 2X the number of slices? > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't need the DSP logic, just need to= compare system > > gates. > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, the developement board I want to buy = comes with > > the XC4VLX25, > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 and I need to make sure this has at least t= he gate > > capacity of the older XC2C1000 > > > =A0 =A0 -steve > > Going from Virtex 2 to Virtex 4, the LUT sizes and LUT to Flip-flop ratio remains the same. So probably easiest to count the flip-flops on the two chips for a rough estimate. However if your design is memory (block RAM) or I/O limited you'll need to probe deeper into the architectural differences. Also V4 is sufficiently faster that you may be able to save logic resources by using higher clock rates and narrower data paths, or more logic levels between pipeline stages. As noted, this is a rough estimate YMMV. Best bet as Nathan pointed out is to port your code and look at the results. DON'T look at the "logic elements" column in the V4 datasheet, this is an inflated number. Count the flops! regards, GaborArticle: 142035
On Jul 22, 12:32=A0pm, stevem <steve.martind...@gmail.com> wrote: > I used a Virtex-II =A0XC2V1000 some time ago. The datasheet says the > capacity is ~1M system gates > with 5,120 slices. > > Now, I am looking at a Virtex-4 XC4VLX25. The datasheet says this has > 10,752 slices but no longer > gives the equivalent "system gates" capacity. > > Question: how do I compare =A0the capcity of XC4VLX25 to the XC2V1000 ? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0is the capacity of XC4VLX25 =A0=3D2X the c= apacity of > XC2V1000, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0since there are 2X the number of slices? > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I don't need the DSP logic, just need to c= ompare system > gates. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Note, the developement board I want to buy co= mes with > the XC4VLX25, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 and I need to make sure this has at least the= gate > capacity of the older XC2C1000 > > =A0 =A0 -steve The part number gives you a rough indication of the relative amount of available logic. Within one family, this indication is fairly accurate. Even between Virtex families it may be good enough for a first evaluation, if you understand that Xilinx dropped two zeros when moving from Virtex 2 to the newer families Virtex-4, -5, and -6. That means your XC4VLX25 is roughly equivalent to a XC2C2500. (When numbers got too large, the French and also the Finns at one time dropped two zeros from their currency, "vive le nouveau franc") Peter AlfkeArticle: 142036
On Wed, 22 Jul 2009 13:16:17 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >On Jul 22, 1:11 pm, Mike Harrison <m...@whitewing.co.uk> wrote: >> On Wed, 22 Jul 2009 04:50:22 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> wrote: >> >On Jul 22, 5:09 am, Mike Harrison <m...@whitewing.co.uk> wrote: >> >> On Tue, 21 Jul 2009 06:08:46 -0700 (PDT), Andy <jonesa...@comcast.net> wrote: > >> >I don't see much utility you would get from excluding particular case >> >branches at all. The case conditions by definition must be >> >- mutually exclusive >> >- cover all cases >> >> >Excluding a particular branch condition with an #ifdef would either >> >violate the 'cover all cases' rule or force that particular branch to >> >now follow the 'when others' default path. I haven't run across a >> >situation where I've ever wanted to code something like that. In any >> >case, you can still use the 'if...then' inside the case branch to >> >branch around the code you would like to exclude. It's roughly the >> >same amount of typing so it shouldn't be any extra work one way or the >> >other. >> >> The situation that comes to mind is a state machine where some of the cases handle debug >> functionality, > >OK, so what is inherently better about this... > >case xyz is > when Blah => > #ifdef DEBUG > -- Put your debug code here > #end if > ...etc... >end case; > >Compared to this... >case xyz is > when Blah => > if DEBUG > -- Put your debug code here > end if; > ...etc... >end case; > >where 'DEBUG' is some boolean. Assuming this will accept a constant for the boolean, so no logic is generated when it is false, and the synthesiser doesn't complain too hard that you are including code that synthesises to nothing, it's close, except in that that the non-used case doesn't take the 'others' branch so there is some possibility it could get into a state it wouldn't get out of - of course the above could be augmented to prevent this, so I'd agree it's pretty much equivalent in practice. However if used in the neighbourhood of a complex nested bunch of If-Then's it would be a little less clear than a preprocessor style thing which is more immediately obvious as being a compile-time choice. >If instead you mean being able to put the #ifdef outside the branch >like this... >case xyz is > #ifdef DEBUG > when Blah => > -- Put your debug code here > #end if > ...etc... >end case; That's more what I was thinking >Then, OK the #ifdef lets you make this edit quicker. But that means >either that you also have to edit the type definition to remove the >'Blah' state or leave it in and let the 'when others' pick it up and >hope that this state bit synthesizes away so it doesn't cost you. The >other way to code this would be... A few extra unused states probably wouldn't be a big deal compared to the logic generated to deal with them. >if (DEBUG and (xyz = Blah) then > -- Put debug code here >else > case xyz is > ... > end case; >end if; > >I don't see any inherent advantage in the situation you alluded to >where #ifdef-ing the entire 'when xxx' statement versus using other >coding styles...but you and others might disagree...that's fine. The point was really that one construct - #ifdef etc. - could be used for pretty much all aspects that may be variable - state-machine behaviour, signal sizes, clock dividers, outputting debug data, pin assignments whatever. This seems a more logical way to do it, as the 'C' guys seem to have figured out a long tome ago.... I think the problem is that VHDL dates back before FPGAS, and ASICs don't tend to have many variants... >> or servicing peripheral devices which are not present in some variants >> Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle' >> state. >> >If the peripherals are not there in some variants, then simply not >connecting any of the output signals from the entity that produces the >unneeded signals to any of the top level entity outputs is >sufficient. The synthesis tool will not produce any logic to >implement anything that doesn't affect an output pin. there may be input-only peripherals, and you may want to make sure no logic is generated as that variant may have alternative functionality that needs the space. The particular design I'm considering is going to end up in the smallest EC1 device and so this may be an issue. >> >- Pin numbers on physical parts never have a need to 'move'. >> >A given >> >board will have a given part which will have pins connected to >> >specific other pins on that board. There will not be any reason to >> >vary these pin numbers for a given design while also maintaining the >> >old pin numbers. >> >> Yes they will - I have a prototype running on a devboard with a 484BGA with tons of extra IOs for >> debug outputs, and the production board will be the same device in 144QFP. >> It is also quite plausible that changes in production boards need pin allocations to change for >> layout reasons, as the board is only 4 layer.. >> > >That would be an example of two different boards with two different >parts...as I mentioned previously either of these two conditions is >not an example of ever having to 'move' a signal, it is an example of >two different designs. Two different designs that share the same subset of functionality, which should also share the same source files, to minimise the effort switching between them/. >Your situation is describing two different boards that use two >different parts that are intended to implement (I'm guessing) the >exact same function (i.e. the same VHDL logic description). Taking >that as the premise, you've got two unique designs that you need to >maintain. >The differences between those two design being all related >to physical part differences and not (or possibly not) any logic >differences. The synthesis process consists of running a tool that >pulls together the following types of information in order to >complete: >- Target device >- Device migration constraints >- Logic description (i.e. the VHDL) >- Pinout constraints >- Timing constraints >- I/O Drive constraints >- Voltage standard constraints > >The logic description is the only thing that should be entered into >the VHDL files. All of the other constraints are inherently device >specific and therefore needed by the synthesis tool (i.e ISPLever), >none of them belong in the VHDL files. They belong in whatever files >the synthesis tool stores them in. Wherever they belong, the ability to easily switch versions would make things a whole lot easier. >The fact that you have two different end targets simply means that you >have two different project files. > >> I would ideally like to have a single project and a simple way to flip it between 'devboard' and >> 'production board' mode, but it seems that this will be far from being as straightforward as it >> would be for a similarly 'varianted' microcontroller project.- Hide quoted text - >> > >If the differences are only in the logic, then this can be handled >pretty simply with a single project file. Synthesis tools allow you >to set top level generics so to 'switch' between debug and release you >would write your code to work with a generic called 'DEBUG' and then >use the synthesis tool to set it however you want it today. When you >get outside of logic and into the other constraints that I mentioned >previously, what you really need then is something different from the >synthesis tool, not the VHDL language. > >I kind of get the impression though that you'd like to treat all of >these variants as if they were somehow really 'the same' in some >sense. But in reality, each environment that a design is in (i.e. the >devboard or the production board) will have their own quirks and >require their own individual debug efforts and you'll likely find the >designs will need to be archived properly so having separate project >files and treating them like separate designs (which they really are) >is a long term better approach. > >Bottom line is, it's just as easy to open a project file from 'File- >>Open...' as it is to otherwise change some setting from 'Debug' to >'Release'. > >Kevin Jennings I will need to look further into what can be done with the project system - I'm fairly new to this, need to get something working in a hurry but am conscious that there will be variants in the future. The IDE and number of files created by my (currently) two source files (VHDL and prefs) is somewhat bewildering - hopefully when I've got this prototype running I'll have time to sit down with all the documentation.... It just seems to me from a 'common sense' viewpoint that although the processes of compiling a C program and syntesising for an FPGA are very different, the requirements for managing variants are almost identical, so a means of doing it in the same way would seem to be a sensible way to do it. A preprocessor which preprocessed all source files in a project, be they VHDL, pin mappings, timing constraints, memory contents in a uniform fashion just seems to be an obvious way to do it... Of course I realise that all FPGA tools have a great deal of 'history' dating way before FPGAs, and everything is now probaly just too ingrained and hard to change to suit the current state of the art. Sort of like QWERTY keyboards....Article: 142037
Hi all, Bit off topic... Anyone know of a company in the UK that can do laser marking or printing custom text on an FPGA. Thanks for your Best regards, EoinArticle: 142038
No, Bitgen has no option to encrypt (despite the misleading comment in the user's guide). All that is required is the binary file itself, none of the implementation files are required. The header is unencrypted, and the trailer is unencrypted: it is only the bits in the middle which get encrypted by the AES256 algorithm, which is public. For those who do not trust us to encrypt the file, they are free to write their own c program to encrypt the file for them. When they compare what we do, and what they do, they find we are not hiding anything. Good security uses public, approved, verifiable methods: nothing is secret or hidden (except your key!). Bad security is instantly recognizable by comments like "proprietary algorithm" or "hidden technique." Relying on obscurity is often a very bad idea: once discovered, and revealed, ALL systems become targets! AustinArticle: 142039
rickman wrote:
> You should also look up GENERATE. That is how to do actual code
> "defines". GENERICS only get you parameters.
I found a dusty example in the stacks:
________________________________________________
architecture synth of e3dsu is
-- constant disabled_for_test : boolean := true;
constant disabled_for_test : boolean := false;
begin
verify : if disabled_for_test generate
rx_clk_dis_cooked <= rx_clk_dis_raw;
bitstream_o <= bitstream_i;
end generate verify;
normal : if not disabled_for_test generate
overhead : process (rx_clk, reset) is
-- pipelined cooking logic ...
________________________________________________
I find that leaving in live, but unused
or obsolescent code like this
is sometimes more informative
to my future self, than is tiding up.
It covers some of the whyDidHe, whyDidntHe questions,
and can simplify maintenance.
-- Mike Treseler
Article: 142040Mike Harrison wrote: > Of course I realise that all FPGA tools have a great deal of 'history' > dating way before FPGAs, and everything is now probaly just too > ingrained and hard to change to suit the current state of the art. Sort > of like QWERTY keyboards.... I suspect that you've really hit the nail on the head with this statement right here. I also suspect you have a software background (as I do), or at least spend a significant amount of time writing software. Pre-processors (together with project build tools) are very powerful tools, as many multi-platform software projects can attest to. Of course, software has a much longer history of concepts such as cross-platform development, re-use (at the macro level) and layers of abstraction and (more recently) emulation/virtualisation. IMHO the hardware/firmware world (and their tools) have a bit of catching up to do in this area - not through any fault of the practitioners but rather due the very nature of the work and the technologies involved. As we see the line increasingly blur between hardware and software, I'd hope that cross-pollination benefits both areas of engineering. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142041
Mike Treseler wrote: > I find that leaving in live, but unused > or obsolescent code like this > is sometimes more informative > to my future self, than is tiding up. So I'm not the only one!!! Good to know! ;) Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142042
On Jul 22, 5:45 pm, Mike Harrison <m...@whitewing.co.uk> wrote: <snip> > >Then, OK the #ifdef lets you make this edit quicker. But that means > >either that you also have to edit the type definition to remove the > >'Blah' state or leave it in and let the 'when others' pick it up and > >hope that this state bit synthesizes away so it doesn't cost you. The > >other way to code this would be... > > A few extra unused states probably wouldn't be a big deal compared to the logic generated to deal > with them. > I disagree that extra states are not a big deal, but not because of logic resource concerns but due to debug methodology. Typical hardware design flows rely (or should rely) on simulation for logic validation. You setup a testbench (more VHDL that stimulates all the inputs and check the outputs) and run a test case (or cases) that exercises the logic that is under test. When something is 'not right', you enter debug mode but that effort typically would not involve writing or changing code in the thing you're testing (i.e. adding the 'debug' state in your example). Instead it mostly involves eyeballing the time history of signals leading up to the bad thing, all of this information is available in the simulator [1]. Once you find the root cause, you change and re-run the sim. Adding the extra state functionally changes the behaviour of the design, it delays things by a clock cycle or two, it changes the thing you're trying to debug. At worst, this change 'fixes' the problem that you were trying to find...but you don't know why it 'fixed' it At best it is not much more than a waste of time because the entire history of every signal is already available at your disposal, there really is nothing more needed to debug any functional problem. The software methodolgy of adding extra tracing/debug code to home in on the root cause of the problem is not really the right mindset here. In simulation you have access to the entire history of every signal. Software debug typically does not have this entire history at your fingertips. There is also debug on real hardware, but the methodology here is to use logic analyzer resources to get a clue as to what signal(s) seem to be at the root cause of the problem without functionally changing the design at all (i.e. you're passively viewing internal design signals). There's more to it than that, but again if you put functional changes in (like your state machine example) in order to debug a problem...you're probably not debugging in a very effective manner...and you'll be slogging it for a long time. [1] Some people prefer to restart and then step through code, I typically don't, it's a preference thing. > >I don't see any inherent advantage in the situation you alluded to > >where #ifdef-ing the entire 'when xxx' statement versus using other > >coding styles...but you and others might disagree...that's fine. > > The point was really that one construct - #ifdef etc. - could be used for pretty much all aspects > that may be variable - state-machine behaviour, signal sizes, clock dividers, outputting debug data, > pin assignments whatever. Well signal sizes and clock dividers are very easily changable via a 'debug' parameter or any other parameter so those don't really fly [2], [3]. Changing functional behaviour and outputting debug data are things that you should eventually come to realize are not needed as I noted above. Right now you may not be at that realization point. You could 'improve' the language by adding #ifdef, but in the end you'll likely find that it's not nearly as useful as you once thought. There probably are some good use cases for #ifdef being more effective than what is in the language today...I just don't think you've described one where there isn't a more effective mechanism already available without it. [2] Signal size example: signal xyz: std_logic_vector(sel(debug, 15, 7) downto 0); where 'sel' is a function you can write that is basically equivalent to something like the following in C x <= debug ? 15, 7; [3] signal Timer_Counter: natural range 0 to MAX_TIME / CLOCK_PERIOD; where 'MAX_TIME' is a parameter that defines whatever you want the timer to count up to; CLOCK_PERIOD would be the period of the input clock...both are simply parameters that get passed into and control the entity. You could also use the above mentioned 'sel' function to select between two upper ranges as well. > This seems a more logical way to do it, as the 'C' guys seem to have > figured out a long tome ago.... C guys also brought us buffer overruns. > I think the problem is that VHDL dates back before FPGAS, and ASICs don't tend to have many > variants... > Maybe...but VHDL is derived from Ada which is a software language. Ada probably has roots that go back to something earlier too, but the point is that VHDL was birthed from a software language not a hardware one. > >> or servicing peripheral devices which are not present in some variants > >> Obviously 'others' will catch things that are conditionally excluded and take it to the 'idle' > >> state. > > >If the peripherals are not there in some variants, then simply not > >connecting any of the output signals from the entity that produces the > >unneeded signals to any of the top level entity outputs is > >sufficient. The synthesis tool will not produce any logic to > >implement anything that doesn't affect an output pin. > > there may be input-only peripherals, and you may want to make sure no logic is generated as that > variant may have alternative functionality that needs the space. Not sure what you mean by an 'input-only' peripheral, but the bottom line is that entity outputs that do not affect any output pins will get optimized away...take your existing design and connect the clock input to some entity to '0' or leave it unconnected and run ISPLever and watch that entire entity disappear. > The particular design I'm > considering is going to end up in the smallest EC1 device and so this may be an issue. > If paranoid surrounding an entity within a generate statement will do the trick. > > > >> Yes they will - I have a prototype running on a devboard with a 484BGA with tons of extra IOs for > >> debug outputs, and the production board will be the same device in 144QFP. > >> It is also quite plausible that changes in production boards need pin allocations to change for > >> layout reasons, as the board is only 4 layer.. > > >That would be an example of two different boards with two different > >parts...as I mentioned previously either of these two conditions is > >not an example of ever having to 'move' a signal, it is an example of > >two different designs. > > Two different designs that share the same subset of functionality, which should also share the same > source files, to minimise the effort switching between them/. > It's pretty darn easy to switch to (or open in parallel) multiple projects via 'File->Open'...'specially if they're in the MRU list. How is that more difficult than changing some other build setting? Once you've done so (change some build setting), how do you keep track of how a given file was built? You can't exactly peruse the binary output file to check to see how that setting was set. Now you've created a configuration management issue, the only way to know how a particular xyz.bin file was built is to rebuild it. It's that type of thing that then evolves into the design suddenly having some magic read only port that returns some information so you'd know how something was set during the build. Yes you can do that...or you can simply have better configuration management, build procedures and source file control/archiving...that's how you handle it properly. Using the GUI to change settings should only be a more convenient mechanism then directly editing the project file with a text editor. But the end result of that changed file should be under source control management. <snip> > Wherever they belong, the ability to easily switch versions would make things a whole lot easier. See above > > >Kevin Jennings > > I will need to look further into what can be done with the project system - I'm fairly new to this, > need to get something working in a hurry but am conscious that there will be variants in the future. > The IDE and number of files created by my (currently) two source files (VHDL and prefs) is somewhat > bewildering - hopefully when I've got this prototype running I'll have time to sit down with all the > documentation.... > Sounds good...just keep in mind that VHDL is used to describe logic. If you're considering entering 'non-logic' things into those particular source files, you're probably not going about it quite right. > It just seems to me from a 'common sense' viewpoint that although the processes of compiling a C > program and syntesising for an FPGA are very different, the requirements for managing variants are > almost identical, so a means of doing it in the same way would seem to be a sensible way to do it. > A preprocessor which preprocessed all source files in a project, be they VHDL, pin mappings, timing > constraints, memory contents in a uniform fashion just seems to be an obvious way to do it... > OK, but even in the C software world you want to have source file control, config management practices in place. All of what I mentioned above would still apply. Hope I've given you some things to ponder, good luck on your design. Kevin JenningsArticle: 142043
On Jul 22, 8:43=A0pm, Mark McDougall <ma...@vl.com.au> wrote: > Mike Treseler wrote: > > I find that leaving in live, but unused > > or obsolescent code like this > > is sometimes more informative > > to my future self, than is tiding up. > > So I'm not the only one!!! Good to know! ;) > No you're not alone, at least three of us now...but then you also said earlier that you leave in some "obsolete/experimental/irrelevant code without it passing elaboration"...that's a bit different. You're not alone there either, but if I keep something like that around it's commented out. I'd much rather it be live code that really does elaborate and sim. Kevin JenningsArticle: 142044
On Wed, 22 Jul 2009 14:59:17 -0700 (PDT), dowlers <eoindowling@gmail.com> wrote: >Hi all, > >Bit off topic... > >Anyone know of a company in the UK that can do laser marking or >printing custom text on an FPGA. > >Thanks for your >Best regards, > >Eoin Do you want to hide the fact that it's an FPGA? We epoxy pin-fin heatsinks on top. ftp://jjlarkin.lmi.net/DSC01786.JPG JohnArticle: 142045
hi all, I am using SPARTAN - 3AN FPGA . While progaramming the FPGA , it erases , programs and verifiys successfully but at the end, I get PROGRAMMING FAILED status..The reason it says is DONE pin did'nt go high.. But if I erase the on -board DSP and then program FPGA, I get PROGRAMMING SUCCESSFULL. I am not understaning this. DONE signal is supposed to be genearated by FPGA..Why DSP has to be erased? All the required signals for programming like INIT_B , PROG is generated by another on -board microcontroller. Please provide some suggestions.Article: 142046
On Jul 23, 9:31=A0am, saras <saras_rajg...@yahoo.co.in> wrote: > hi all, I am using SPARTAN - 3AN FPGA . While progaramming the FPGA , > it erases , programs and verifiys successfully but at the end, I get > PROGRAMMING FAILED status..The reason it says is DONE pin did'nt go > high.. > But if I erase the on -board DSP and then program FPGA, I get > PROGRAMMING SUCCESSFULL. I am not understaning this. DONE signal is > supposed to be genearated by FPGA..Why DSP has to be erased? All the > required signals for programming like INIT_B , PROG is generated by > another on -board =A0microcontroller. Please provide some suggestions. erasable DSP? what are you talking about ;)? what are you programming? the onchip SPI flash? or loading config via slave serial using onboard MCU? what is the DSP doing?? a real mystery (to anyone except you) AnttiArticle: 142047
On Jul 23, 12:02=A0pm, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Jul 23, 9:31=A0am, saras <saras_rajg...@yahoo.co.in> wrote: > > > hi all, I am using SPARTAN - 3AN FPGA . While progaramming the FPGA , > > it erases , programs and verifiys successfully but at the end, I get > > PROGRAMMING FAILED status..The reason it says is DONE pin did'nt go > > high.. > > But if I erase the on -board DSP and then program FPGA, I get > > PROGRAMMING SUCCESSFULL. I am not understaning this. DONE signal is > > supposed to be genearated by FPGA..Why DSP has to be erased? All the > > required signals for programming like INIT_B , PROG is generated by > > another on -board =A0microcontroller. Please provide some suggestions. > > erasable DSP? > > what are you talking about ;)? >>>>>>> >> It is flash based DSP chip, which can be erased using the DSP Jt= ag debugger. > what are you programming? the onchip SPI flash? > or loading config via slave serial using onboard MCU? >>> >>I'm flashing the onchip SPI flash for now, but will be done by MCU in= future.For now it is in dvevelopment stage and I'm using Xilix Jtag cable = to program the onchip SPI flash. > what is the DSP doing?? > >>> I donno much about its functinality but I'm using its clock... > a real mystery (to anyone except you) > > AnttiArticle: 142048
Philip <philip.freidin@gmail.com> writes: > (the following may well be fiction) <snip> Brilliant - thanks! MartinArticle: 142049
> > Do you want to hide the fact that it's an FPGA? We epoxy pin-fin > heatsinks on top. > > ftp://jjlarkin.lmi.net/DSC01786.JPG > > John Not really hide but advertise company name. It is a non volotile FPGA - XP2. I have found a company - Action Circuits. Eoin
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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