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
Vaugn, Shell and pea game: no, you do not get the entire benefit of reduced C. Also, not all layer dielectrics are Lo-K. For example, the clock tree is near the top, where regular dielectric is used, isn't it? At least, we evaluated both with, and without Lo-K devices (from the same masks and fab), and were surprised to see only a 5% improvement. Did you do the same experiment? We were surprised. Turns out, there is a lot more in the equations that just C. If it was just that simple, extracted simulations in spice would be unneeded. Austin Vaughn Betz wrote: > Thanks to John for a thoughtful posting. I enjoy reading this newsgroup and > helping customers when I can. I also can't resist correcting errors / > misrepresentations when I see them. I don't think name calling or hyperbole > is enjoyable for either the people posting or the people reading posts, so I > appreciate the effort to encourage civility. > > Hopefully correcting the error below will not cause a firestorm in response: > > >>>It appears Low-K is a win for Altera. >> >>5% less C, means 5% less core power, and ~5% more speed over regular K. >>All good. > > > FSG dielectric (Virtex4) has a dielectric constant of 3.7. Black diamond > (Stratix II) has a dielectric constant of about 3.0. See > http://www.micromagazine.com/archive/04/03/applied.html for details on the > dielectric constant of black diamond. That means you get a 19% capacitance > reduction with black diamond vs. FSG. Everybody remembers capacitance is > directly proportional to dielectric constant, right? :). > > So all metal capacitance drops by 19%. Nowadays metal capacitance is about > 2/3 of the switching capacitance in an FPGA, while the remaining 1/3 is gate > & diffusion capacitance that is unaffected by low-k (since it's transistor > capacitance rather than in the metal stack). So, you get an ~13% speed up > and ~13% dynamic power reduction from the use of a low-k dielectric. > > Vaughn Betz > Altera > [v b e t z (at) altera.com] > >Article: 79276
I am trying to put the PPC405 asleep on a VirtexIIPro ML310 Xilinx development board and not have a lot of luck. I'm running VxWorks and have written a little application that toggles an LED so that I know the task is running. I've tried two methods--with drastically different results-- but neither of which do everything I need. First try: I loaded my app that toggles LEDs via a Tornado shell. Spawn the LED toggler. Note that via Tornado shell, I see LED toggler in the task list at an "i" command. Note that via the serial shell, I cannot see LED toggler in the task list at an "i" command. Disable PIT, so only a UART or network source interrupt will awaken me (ie no sysClk/timer interrupts) Put to sleep via MSR[WE]. Observed LED quits toggle-- as expected. Then, via a SERIAL shell, I type "i", and vxWorks awoke and printed the tasks data as expected-but the LED toggler did not resume execution. Second try: I moved all this code into UsrAppInit and then programmatically, spawned the LED toggler. Wait a few secs (so I can observe LED on scope). Then Disable PIT and put to sleep. Now, I try to awaken the PPC405 via the serial connection. I cannot seem to waken the PPC at all. If/when it wakens, the next line of code in usrAppInit would have printed out an "Awoken" message--but I never see this happen. Note that the Msr register is set to 0x00069200 to initiate the sleep-which should set the sleep bits, and enable critical and external interrupts (though the PIT as a possible feeder to External Interrupt has been disabled via a write to TCR of 0x00040000...) Someone else had mentioned to me the need for possible sync and orderly execution before putting the PPC to sleep, so I added "sync, isync, and eieio" code immediately prior to the set MSR[WE] bit, but this made no difference. Any ideas? Thanks PaulArticle: 79277
Hi everyone... Yeah, it seems though, that there is no difficulty counting that fast! So I don't need to worry at all ;-) That's a nice thing! Thanks /PrebenArticle: 79278
I have tried looking for documentation on the current requirements for FPGAs. I am trying to select the most efficient and low power voltage regulators to provide the 3.3, 2.5 and 1.2 voltages to a Spartan 3 (PQ208). The input power supply is 5V. I had selected a 100mA Texas Instruments voltage reuglator. But I am still curious if I am violating any current requirements for the FPGA pins. The spartan 3 documentation talks about quiescent current limitations which seem to be pretty low at around maximum of 70mA. Of course the goal is to have the most low power regulators so that thermal power generation is at the lowest. Let me know if you have any expereinces with different voltage regulators. Thanks -Yaju N BYU ECEN DeptArticle: 79279
In article <1108532703.846896.232700@z14g2000cwz.googlegroups.com>, Marc Randolph <mrand@my-deja.com> wrote: >Anyone else out there see this? Anyone seeing something that a V4 or >S2 won't do fairly well, that you think someone might want or need in >the next year or three? Yes, I do. Gigabit Copper has become this all purpose glue: a cheap way of connecting stuff together. Currently, it takes an external PHY or MAC/PHY: not a big deal on an expensive board with an expensive FPGA, but its a big deal on a cheap board. I'd love to see a Spartan/Cyclone FX, with multiple 10/100/1000-T MAC/PHYs as hardcores, from one on the smallest part to perhaps as many as eight. I see a world which needs a ton of high speed, low cost programmable Gb network devices (mostly security applications, but who knows what else?) Never happen, but an interesting thought. -- Nicholas C. Weaver. to reply email to "nweaver" at the domain icsi.berkeley.eduArticle: 79280
I assume you're going to use switching regulators to generate all voltages directly from 5 volts, this would be the most efficient way to do things. I use the Linear Technologies LTC3411 for this sort of application because it's readily available in small quantities, takes in up to 5.5 volts and outputs down to .8 volts, and it's above 90% efficient for a wide range of output currents, from 10 mA to well over 500 mA. It can supply up to 1.25 amps, though you need big tantalum caps to keep the ripple down when you get up there in current. It does have a few tradeoffs though -- it seems Linear's parts are more expensive than the big manufacturers, and this part will take up more board space than some other solutions and has a bigger BOM, adding to the cost. Your current draw is going to vary widely depending on your design, and will always be more than the quiescent current. You can easily burn a couple watts in a medium-sized FPGA, and 5-10 watts in a bigger FPGA running at high speed.Article: 79281
hi Well, in your construction, if two uBLAZEs try to write (or read) to shared variables at the same time, what happens? Another interesting thing will be a programming. In XPS, each processor has its own main() routine. In case they are communicating with shared variables, how can we synchronize two program ? By the way, what we want is to do 'one' job (with two processors) ! Is it possible to run only one main() routine ? thankyou again for this 'what if' questionsArticle: 79282
Hi Yaju N wrote: > I have tried looking for documentation on the current requirements for > FPGAs. > > I am trying to select the most efficient and low power voltage > regulators to provide the 3.3, 2.5 and 1.2 voltages to a Spartan 3 > (PQ208). The input power supply is 5V. > > I had selected a 100mA Texas Instruments voltage reuglator. But I am > still curious if I am violating any current requirements for the FPGA > pins. The spartan 3 documentation talks about quiescent current > limitations which seem to be pretty low at around maximum of 70mA. > > Of course the goal is to have the most low power regulators so that > thermal power generation is at the lowest. Let me know if you have any > expereinces with different voltage regulators. Just estimate your power requirement with the on-line xilinx tools. The power requirements of FPGA vary in function of the design you load in it. A 64bits 200Mhz DDR interface using DCI is not gonna use the same power as a a simple slow I2C interface ... SylvainArticle: 79283
Hi John,
The reason for the error message is that you are trying to use a
cross-hierarchy defparam, which means setting aparameter on an instance
several levels deep in the hierarchy. That is not supported today -- you can
only set parameters on a module you are instantiating, not on any of its
children. Instead, add a new parameter to the megawizard wrappper and pass
that down. An example of a modified altsyncram file, with the edited lines
marked with // EDIT. is shown below:
Here is an example of what needs to be done:
// megafunction wizard: %ALTSYNCRAM%
// GENERATION: STANDARD
// VERSION: WM1.0
// MODULE: altsyncram
// ============================================================
// File Name: my_altsyncram.v
// Megafunction Name(s):
// altsyncram
// ============================================================
// ************************************************************
// THIS IS A WIZARD-GENERATED FILE. DO NOT EDIT THIS FILE!
//
// 5.0 Internal Build 111 02/14/2005 SJ Full Version
// ************************************************************
//Copyright (C) 1991-2005 Altera Corporation
//Your use of Altera Corporation's design tools, logic functions
//and other software and tools, and its AMPP partner logic
//functions, and any output files any of the foregoing
//(including device programming or simulation files), and any
//associated documentation or information are expressly subject
//to the terms and conditions of the Altera Program License
//Subscription Agreement, Altera MegaCore Function License
//Agreement, or other applicable license agreement, including,
//without limitation, that your use is for the sole purpose of
//programming logic devices manufactured by Altera and sold by
//Altera or its authorized distributors. Please refer to the
//applicable agreement for further details.
// synopsys translate_off
`timescale 1 ps / 1 ps
// synopsys translate_on
module my_altsyncram (
data,
wren,
wraddress,
rdaddress,
clock,
q);
parameter my_hex_file=""; // EDIT
input [1:0] data;
input wren;
input [3:0] wraddress;
input [3:0] rdaddress;
input clock;
output [1:0] q;
wire [1:0] sub_wire0;
wire [1:0] q = sub_wire0[1:0];
altsyncram altsyncram_component (
.wren_a (wren),
.clock0 (clock),
.address_a (wraddress),
.address_b (rdaddress),
.data_a (data),
.q_b (sub_wire0),
.aclr0 (1'b0),
.aclr1 (1'b0),
.addressstall_a (1'b0),
.addressstall_b (1'b0),
.byteena_a (1'b1),
.byteena_b (1'b1),
.clock1 (1'b1),
.clocken0 (1'b1),
.clocken1 (1'b1),
.data_b (2'b11),
.q_a (),
.rden_b (1'b1),
.wren_b (1'b0));
defparam
altsyncram_component.operation_mode = "DUAL_PORT",
altsyncram_component.width_a = 2,
altsyncram_component.widthad_a = 4,
altsyncram_component.numwords_a = 16,
altsyncram_component.width_b = 2,
altsyncram_component.widthad_b = 4,
altsyncram_component.numwords_b = 16,
altsyncram_component.lpm_type = "altsyncram",
altsyncram_component.width_byteena_a = 1,
altsyncram_component.outdata_reg_b = "UNREGISTERED",
altsyncram_component.indata_aclr_a = "NONE",
altsyncram_component.wrcontrol_aclr_a = "NONE",
altsyncram_component.address_aclr_a = "NONE",
altsyncram_component.address_reg_b = "CLOCK0",
altsyncram_component.address_aclr_b = "NONE",
altsyncram_component.outdata_aclr_b = "NONE",
altsyncram_component.read_during_write_mode_mixed_ports = "DONT_CARE",
`ifdef NO_PLI
altsyncram_component.init_file = "foo.rif"
`else
altsyncram_component.init_file = my_hex_file // EDIT
`endif
,
altsyncram_component.intended_device_family = "Stratix";
endmodule
// ============================================================
// CNX file retrieval info (lines remobed below)
// ============================================================
.....
// Retrieval info: PRIVATE: BlankMemory NUMERIC "0"
// Retrieval info: PRIVATE: MIFfilename STRING "foo.hex"
// ...
// Retrieval info: GEN_FILE: TYPE_NORMAL my_altsyncram_wave*.jpg FALSE
With regard to your question on string parameter: Verilog 1995 does support
string parameters, so this is not an issue.
Hope this helps,
Subroto Datta
Altera Corp.
"John Rible" <jrible@sandpipers.com> wrote in message
news:cuuoep0fmo@enews4.newsguy.com...
>
> Subroto Datta wrote:
>> Hi John,
>>
>> You will need to expose the parameter that is used for the .hex
>> initialization file. The MegaWizard-generated Verilog file will have a
>> line saying defparam <instname>.INIT_FILE = "foo.hex"; that parameter
>> needs to be added to the MegaWizard-generated module and passed down.
>> Then assign a unique value for that parameter to each instantiation of
>> the wizard-generated ROM sub-module.
>
> I've already tried using defparam (without adding it to the top file) and
> got:
> Error: Verilog HDL or VHDL error at c18m.v(78): Unconverted VERI-2009: no
> support for cross-hierarchy defparam id
> c.RS.m.altsyncram_component.init_file
>
> Tomorrow I'll 'expose' the parameter. Also, Verilog 1995 didn't support
> string parameters; is that the problem?
>
>> As for the question on inversions: all our blocks have programmable
>> inversions on the inputs, so we allow inverts to be absorbed across
>> hierarchy boundaries. The solution would be to insert an LCELL buffer to
>> prevent the programmable inversion being propagated.
>>
>>
>>
>> Where the code has
>>
>>
>>
>> wire inverted_signal;
>>
>>
>>
>> You will need to add
>>
>> wire buffered_inverted_signal;
>>
>> lcell lcell_inst (inverted_signal, buffered_inverted_signal);
>>
>>
>>
>> and this will prevent the inversion propagating. However, It will use up
>> an LE.
>
> Thanks a lot!
>
> -John
>
>> Hope this helps,
>>
>> Subroto Datta
>>
>> Altera Corp.
Article: 79284Nicholas Weaver wrote: > In article <1108532703.846896.232700@z14g2000cwz.googlegroups.com>, > Marc Randolph <mrand@my-deja.com> wrote: > > >>Anyone else out there see this? Anyone seeing something that a V4 or >>S2 won't do fairly well, that you think someone might want or need in >>the next year or three? > > > Yes, I do. Gigabit Copper has become this all purpose glue: a cheap > way of connecting stuff together. Currently, it takes an external PHY > or MAC/PHY: not a big deal on an expensive board with an expensive > FPGA, but its a big deal on a cheap board. > > I'd love to see a Spartan/Cyclone FX, with multiple 10/100/1000-T > MAC/PHYs as hardcores, from one on the smallest part to perhaps as > many as eight. > > I see a world which needs a ton of high speed, low cost programmable > Gb network devices (mostly security applications, but who knows what > else?) > > Never happen, but an interesting thought. This chip was interesting, as it includes SATA PHY, at 1.5GHz http://www.oxsemi.com/press/feb05/index.html so I am sure we will see the same in FPGAs. Longer range PHYs, probably are determined by power/voltage swings -jgArticle: 79285
That is standard multi-programming handling. I would connect two FSL between the two MicroBlazes and let them agree on who should use shared resources. Göran Elinore wrote: > hi > > Well, in your construction, if two uBLAZEs try to write (or read) to > shared variables at the same time, what happens? > > Another interesting thing will be a programming. In XPS, each processor > has its own main() routine. In case they are communicating with shared > variables, how can we synchronize two program ? > By the way, what we want is to do 'one' job (with two processors) ! Is > it possible to run only one main() routine ? > thankyou again for this 'what if' questions >Article: 79286
I am trying to implement a different flavor of XAPP224 in order to have a 270Mbps serial to parallel converter (DVB-ASI application) in a XC2S200E-6 device. I thought to divide the VCO's 270MHz by two, to produce two 135MHz clocks and use a carry chain delay arrangement to shift one clock's phase. Then building a double serial-to-parallel and registering both outputs together I may end with the expected 10 bits. In this frequency I know it is hard to implement but if feasible I would appreciate your considerations and recomendations. The XAPP250 uses this delay approach but talks only about V2 and V2Pro end devices. Also, the XAPP250 says there is a ZIP file with VHDL source but the file I've found has Verilog files only. It could be translated to VHDL but to make things worst that application uses Symplicity (with synthesis attributes not available in XST) and I cannot afford to have a Symplicity tool to work with. I understand I shall need to design the whole circuit using absolute positioning of fabric resources. But, of course, better to start if I know I can make it working on this device. Of course there is no possibility to change device (to Spartan-3 or V2) at this moment. So, is there a hope for my case? Thanks for your attention.Article: 79287
Brian Drummond wrote:
> Since the input waveform is a high purity sinewave, there is one point
> to be careful about, if that purity is important, e.g. it is a local
> oscillator in a radio receiver.
Yes, it is a very low jitter reference clock for a PLL-based
local oscillator and a strobe of a high-speed ADC (AD6644).
> If you are generating very fast edges on a 3V to 5VP-P square wave, it
> is very easy to couple a tiny fraction of those edges back onto the
> input (through the input buffer and attenuator, through the ground plane
> or even through the air) and degrade your LO purity (and interference
> rejection) by 40dB or so.
The oscillator is carefully screened, so the only possibility of
coupling is through the power lines. There is a lot of ferrite
beads inside the oscillator box, an LDO and -- finally -- an
active noise canceller, so I think that this way of coupling is
impossible.
Best regards
Piotr Wyderski
Article: 79288Hi Jim, Thanks mate! Funny old answer, that 10078! Seems like someone got two records mixed together. Cheers, Syms. "Jim Wu" <nospam@nospam.com> wrote in message news:cuviqu$bn01@cliff.xsj.xilinx.com... > Check the following answer record http://tinyurl.com/538veArticle: 79289
On 15 Feb 2005 12:31:32 -0800, "brade@colmek.com" <brade@colmek.com> wrote: >I recently purchased an Avnet Spartan 3 Evaluation Board but the >supplied EDK *.xbd file doesn't have anything in it with PCI. Has >anyone out there modified the *.xbd file to allow the Xilinx Base >System Builder to create a PCI Bridge? You need to supply a PCI core from elsewhere. Xilinx will sell you one for about $1200(?) for single-project use. Alternatively there are(were) at least 2 in the open-source category - opencores.org have one, and there was one written by a guy in Finland but I think his website may have been taken down. Others exist - Kevin Brace was developing one, which may be available for sale ... and I'd be interested to hear of any others too! Caveat: some of these are target-only... - BrianArticle: 79290
On 15 Feb 2005 21:45:03 -0800, "Marc Randolph" <mrand@my-deja.com> wrote: >glen herrmannsfeldt wrote: >> Austin Lesea wrote: >> (big snip) >> Many designs could easily only require on half or one tenth of >> what current FPGAs are capable of, and still be worth putting in >> an FPGA. For those, the slowest devices, especially with lower >> static power, might be very useful. > >Something similar crossed my mind when we first talked with our local >Xilinx sales rep several months ago about how the S2 compares to the >V4. >Anyone else out there see this? Anyone seeing something that a V4 or >S2 won't do fairly well, that you think someone might want or need in >the next year or three? I suspect that as hot-spots are tackled, new ones will appear. For example, multipliers used to take up a huge area. I'm finding big multiplexers to be an issue, for a couple of reasons. Barrel shifters, and normalisation (which will become hugely important if the floating point synthesisable packages take off) for one, and the replacement of internal tri-states with mux logic for another. They tend to be quite large, not very well structured (for floorplanning), and not particularly well pipelined, as they tend to synthesise to several levels of logic without using the slice FFs. On a couple of recent designs I'd estimate 30 to 50% of the area has been multiplexers (and I didn't have the option of using multipliers as barrel shifters). MUXF5s help ... a little. I believe something like a 4/8/16 to 1 MUX function 16(18?) bits in width (preferably also configurable as a barrel shifter) would be worthy of consideration as a next generation block function (or MegaFunction) - BrianArticle: 79291
My current(ho ho) favourite switcher is the LTC3414. 4A output. As Chris says, maybe more expensive than some, but ease of use and time to market is key in my apps. Don't use Tants, they're made of pure evil! Either ceramic caps up to 100uF or Panasonic's 5mOhm ESR specialty polymer electrolytics up to 470uF. I usually defeat the burst mode. One less noise source to worry about. All IMHO, YMMV, hope this gives you some ideas! Best, Syms. <Chris> wrote in message news:ee8be5d.0@webx.sUN8CHnE... > I assume you're going to use switching regulators to generate all voltages directly from 5 volts, this would be the most efficient way to do things. I use the Linear Technologies LTC3411 for this sort of application because it's readily available in small quantities, takes in up to 5.5 volts and outputs down to .8 volts, and it's above 90% efficient for a wide range of output currents, from 10 mA to well over 500 mA. It can supply up to 1.25 amps, though you need big tantalum caps to keep the ripple down when you get up there in current. It does have a few tradeoffs though -- it seems Linear's parts are more expensive than the big manufacturers, and this part will take up more board space than some other solutions and has a bigger BOM, adding to the cost. > > Your current draw is going to vary widely depending on your design, and will always be more than the quiescent current. You can easily burn a couple watts in a medium-sized FPGA, and 5-10 watts in a bigger FPGA running at high speed.Article: 79292
Hi everybody, Has anyone done DNL and INL calculation using an FPGA yet? Basically I have an 8 bits ramp coming in and I need to calculate DNL and INL. Thanks, ALArticle: 79293
Augusto, I assume you know that every Virtex-4 drvice offers exactly that function, at up to 3 times higher speed, and on every pin independently. So, if you are flexible, it's all done for you... Peter Alfke, Xilinx ApplicationsArticle: 79294
I don't think that is my problem. I have purchased the Xilinx PCI core and I am able to use Base System Builder to generate PCI implementations for other boards but when I do it for the Avnet board and do a Generate Netlist I get the following errors: Check port drivers... ERROR:MDT - pci_clk_s (PCLK) - Z:\Demo6\system.mhs:266 - No driver found for connector! ERROR:MDT - pci_clk_s (CLKIN) - Z:\Demo6\system.mhs:286 - No driver found for connector! ERROR:MDT - pci_feedback_s (CLKFB) - Z:\Demo6\system.mhs:288 - No driver found for connector! ERROR:MDT - sys_clk_s (CLK) - Z:\Demo6\system.mhs:74 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:88 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:100 - No driver found for connector! ERROR:MDT - sys_clk_s (LMB_Clk) - Z:\Demo6\system.mhs:114 - No driver found for connector! ERROR:MDT - sys_clk_s (LMB_Clk) - Z:\Demo6\system.mhs:122 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:161 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:184 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:202 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:214 - No driver found for connector! ERROR:MDT - sys_clk_s (OPB_Clk) - Z:\Demo6\system.mhs:255 - No driver found for connector! Brian Drummond wrote: > On 15 Feb 2005 12:31:32 -0800, "brade@colmek.com" <brade@colmek.com> > wrote: > > >I recently purchased an Avnet Spartan 3 Evaluation Board but the > >supplied EDK *.xbd file doesn't have anything in it with PCI. Has > >anyone out there modified the *.xbd file to allow the Xilinx Base > >System Builder to create a PCI Bridge? > > You need to supply a PCI core from elsewhere. > > Xilinx will sell you one for about $1200(?) for single-project use. > Alternatively there are(were) at least 2 in the open-source category - > opencores.org have one, and there was one written by a guy in Finland > but I think his website may have been taken down. > > Others exist - Kevin Brace was developing one, which may be available > for sale ... and I'd be interested to hear of any others too! > > Caveat: some of these are target-only... > > - BrianArticle: 79295
Since FPGAs aren't precise analog devices, what are you expecting the FPGA to do? "AL" <ann.lai@analog.com> wrote in message news:ee8be82.-1@webx.sUN8CHnE... > Hi everybody, > > Has anyone done DNL and INL calculation using an FPGA yet? Basically I have an 8 bits ramp coming in and I need to calculate DNL and INL. > > Thanks, ALArticle: 79296
Brian Drummond wrote: > On 15 Feb 2005 21:45:03 -0800, "Marc Randolph" <mrand@my-deja.com> > wrote: > > >glen herrmannsfeldt wrote: > >> Austin Lesea wrote: > >> (big snip) > > >> Many designs could easily only require on half or one tenth of > >> what current FPGAs are capable of, and still be worth putting in > >> an FPGA. For those, the slowest devices, especially with lower > >> static power, might be very useful. > > > >Something similar crossed my mind when we first talked with our local > >Xilinx sales rep several months ago about how the S2 compares to the > >V4. > > >Anyone else out there see this? Anyone seeing something that a V4 or > >S2 won't do fairly well, that you think someone might want or need in > >the next year or three? > > I suspect that as hot-spots are tackled, new ones will appear. For > example, multipliers used to take up a huge area. > > I'm finding big multiplexers to be an issue, for a couple of reasons. > Barrel shifters, and normalisation (which will become hugely important > if the floating point synthesisable packages take off) for one, and the > replacement of internal tri-states with mux logic for another. > > They tend to be quite large, not very well structured (for > floorplanning), and not particularly well pipelined, as they tend to > synthesise to several levels of logic without using the slice FFs. > > On a couple of recent designs I'd estimate 30 to 50% of the area has > been multiplexers (and I didn't have the option of using multipliers as > barrel shifters). MUXF5s help ... a little. > > I believe something like a 4/8/16 to 1 MUX function 16(18?) bits in > width (preferably also configurable as a barrel shifter) would be worthy > of consideration as a next generation block function (or MegaFunction) Howdy Brian, Now knowing your device size, I'm not sure how many muxes you have, but any way you think of it, 50% of an FPGA for muxes is quite a bit. But I think the V4 DSP block does most of what you've discussed (wide muxes, barrel shifters, and counters), doesn't it? Have fun, MarcArticle: 79297
Nicholas Weaver wrote: > In article <1108532703.846896.232700@z14g2000cwz.googlegroups.com>, > Marc Randolph <mrand@my-deja.com> wrote: > > >Anyone else out there see this? Anyone seeing something that a V4 or > >S2 won't do fairly well, that you think someone might want or need in > >the next year or three? > > Yes, I do. Gigabit Copper has become this all purpose glue: a cheap > way of connecting stuff together. Currently, it takes an external PHY > or MAC/PHY: not a big deal on an expensive board with an expensive > FPGA, but its a big deal on a cheap board. > > I'd love to see a Spartan/Cyclone FX, with multiple 10/100/1000-T > MAC/PHYs as hardcores, from one on the smallest part to perhaps as > many as eight. > > I see a world which needs a ton of high speed, low cost programmable > Gb network devices (mostly security applications, but who knows what > else?) > > Never happen, but an interesting thought. Yes, it is - and I agree that there are tons of applications just begging for gigabit ethernet connectivity (PVR/DVR's or HDTV's, not to mention almost all "normal" communication or networking equipment). But the analog circuitry required to support the five level (!) signaling that gigabit copper uses seems like a little much to ask of a multi-hundred MHz digital device with tens of thousands of gates toggling all at the same time. Even so, you gave me an idea... what if you could have the analog front end in a cheapish external device and use the internal DSP blocks to do the signal processing? Of course, to make it worthwhile, that cheapish device would need to be at least 3 or 4x lower cost than the $10/port gigabit copper phy's you can buy right now. As you said - unlikely that it will ever happen. The MAC's are a completely different issue. They could do that easily right now, and in all devices. So I think you did hit on something there. There is no reason that every FPGA couldn't ship with 1 or 4 or 12 of them (or for a start, at least more than one family). When I first heard that the 4VFX20 devices were going to have 8 MGT's, I immedately started thinking of all the things I could do not only with those 8 MGT's, but with the 8 hard MAC's they would surely include. Only later did I discover they put only 2 MAC's in the FX20!?! The MAC's obviously aren't designed with networking/telecommunications equipment in mind or they would have included one for each MGT. Instead, they seem to have made it 2x the number of 405 processors. Great idea though! Have fun, MarcArticle: 79298
Peter Alfke wrote: > Augusto, I assume you know that every Virtex-4 drvice offers exactly > that function, at up to 3 times higher speed, and on every pin > independently. > So, if you are flexible, it's all done for you... > Peter Alfke, Xilinx Applications Or if the V4 is too expensive for Augusto's application, he could also check out the Spartan 3. For some parts and applications, S3's are even cheaper than Spartan II's, with more, better, and especially important for his application, faster resources. Spartan IIE is like the Virtex-E... and I'd be a little shy of pushing the Virtex-E to 270 MHz. I seem to recall Ray doing some impressive stuff with Virtex-E's... maybe he can chime in. After all, there won't be too much logic running at that rate (some muxes and some flops... that's all, right?). Good luck, MarcArticle: 79299
Subroto- Tried it LATE last night. It works. And now the error message makes sense; is this difference from the Verilog LRM documented anywhere? Thank you, -John Subroto Datta wrote: > Hi John, > > The reason for the error message is that you are trying to use a > cross-hierarchy defparam, which means setting a parameter on an instance > several levels deep in the hierarchy. That is not supported today -- you can > only set parameters on a module you are instantiating, not on any of its > children. Instead, add a new parameter to the megawizard wrappper and pass > that down. An example of a modified altsyncram file, with the edited lines > marked with // EDIT. is shown below: ...snip...
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