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
Hi Antti, > In XCELL issue 52, page 19 Xilinx claims that: > > V4-PowerPC reduces power 10:1 compared to FPGA Fabric built version (of > PowerPC) > > but that means Xilinx has internally a PowerPC Soft Core IP? > If they dont then could not measure the power difference :) > I wonder why there is no information about the xilinx soft-core PowerPC at > all? I'm absolutely positive that IBM has produced a synthesizable PowerPC core that Xilinx has a license for. How else would they be able to verify the functionality of the V2Pro and V4 devices? I think that if you contact your local IBM fab and exchange enough money, that you too can have your own shiny, glistening PowerPC softcore, filling half your huge FPGA and running at 32MHz. Best regards, BenArticle: 81351
> Much better !
Thanks
>> entity holdoffcontroller is
>> Port ( clk : in std_logic;
>> reset : in std_logic;
>> save : in std_logic;
>> trig : in std_logic;
>> read : in std_logic;
>> holdoff : in std_logic;
>> hold : out std_logic := '0';
>
> -- I wouldn't initialize the output in the port.
> -- nice trick for optional inputs though.
Done! But why should I?
> -- I would rather use RTL rather than "behavioral" (cosmetic)
RTL meaning?
>> STATEMACHINE: block
>> signal current_state : states := stateStart;
>
> No. It's "bad" enough this initialization does exist in VHDL
> without you writing it....
> The issue of integer range & enums is that they are "automatically"
> initialized (at simulation) with the leftmost value, so you won't
> notice they may not be in hardware (synthesis).
So the initialization won't be like this in the real hardware - or did I
misunderstand you there?
> But since you've coded the async reset (almost) correctly,
> it's not an issue.
>
> Just don't initialize signals at declaration in RTL code.
>
>> begin
>> stateRegister : process(clk, reset)
>> begin
>> if reset = '1' then
>> current_state <= stateStart;
>
> Bad bad !
> you forgot to reset all the FlipFlops you've created below !
> (hold in this case, but any other signal on left side of an
> assignment should be reset also).
> This is bad because reset will show up in the datapath as an enable :-(
Why will reset show up as enable?
> Don't write this line (assign to self). It's useless.
>
> The 2-process version "next_state <= current_state" was necessary
> to code the "implied else" and avoid latches, but you don't need
> this in the one-process style.
Well, I'm getting latches for some of the signals I start to assign?
>> process(current_state)
>> begin
>
>
> state <= (others=>'-'); -- play it safe !!!
>
>> case current_state is
>> when stateStart => state <= "00001";
>> when stateWait => state <= "00010";
>> when stateTrigger => state <= "00100";
>> when stateHold => state <= "01000";
>> when stateRead => state <= "10000";
>> end case;
>> end process;
>> end block;
>
>
> I would at least make a default assignment on top to (others=>'-')
> as shown above, in the hope that the synthesis tool will create
> an optimized one-hot decoder in any (encoding method) case and
> will never create latches.
Okay! I didn't know that!
> It's still a VERY good idea to check what synthesis will do (should
> be just wires here).
>
> Last comment : I would use block / endblock only to restrict
> the scope of some signals. Since the state information is global
> (it even goes up in the hierarchy), then the block section
> (imho) is not useful here.
Yeah, I just didn't remove it!
The total new and even more perfected statemachine:
-----
entity holdoffcontroller is
Port ( clk : in std_logic;
reset : in std_logic;
prescale : in std_logic; -- asserted everytime data-sample
should be saved
trig : in std_logic;
read : in std_logic;
holdoff : in std_logic;
holdoff_enable : out std_logic;
holdoff_reset : out std_logic;
hold : out std_logic);
end holdoffcontroller;
architecture Behavioral of holdoffcontroller is
type states is (stateStart, stateWait, stateTrigger, stateHold,
stateRead);
signal holdoff_enable_i : std_logic;
signal holdoff_reset_i : std_logic;
signal current_state : states;
begin
stateRegister : process(clk, reset)
begin
if reset = '1' then
current_state <= stateStart;
holdoff_enable_i <= '0';
holdoff_reset_i <= '1';
hold <= '0';
elsif rising_edge(clk) then
case current_state is
when stateStart =>
holdoff_enable_i <= '0';
holdoff_reset_i <= '1';
hold <= '0';
if holdoff = '0' and read = '0' and trig = '0' then
current_state <= stateWait;
holdoff_enable_i <= '0';
holdoff_reset_i <= '1';
hold <= '0';
end if;
when stateWait =>
if trig = '1' then
current_state <= stateTrigger;
holdoff_enable_i <= '1';
holdoff_reset_i <= '0';
hold <= '1';
end if;
when stateTrigger =>
holdoff_enable_i <= '1';
holdoff_reset_i <= '0';
hold <= '1';
if holdoff = '1' and read = '0' then
current_state <= stateHold;
holdoff_enable_i <= '0';
holdoff_reset_i <= '0';
hold <= '1';
end if;
if holdoff = '0' and read = '1' then
current_state <= stateRead;
holdoff_enable_i <= '1';
holdoff_reset_i <= '0';
hold <= '1';
end if;
if holdoff = '1' and read = '1' then
current_state <= stateStart;
holdoff_enable_i <= '0';
holdoff_reset_i <= '1';
hold <= '0';
end if;
when stateHold =>
holdoff_enable_i <= '0';
holdoff_reset_i <= '0';
hold <= '1';
if read = '1' then
current_state <= stateStart;
holdoff_enable_i <= '0';
holdoff_reset_i <= '1';
hold <= '0';
end if;
when stateRead =>
holdoff_enable_i <= '1';
holdoff_reset_i <= '0';
hold <= '1';
if holdoff = '1' then
current_state <= stateStart;
holdoff_enable_i <= '0';
holdoff_reset_i <= '1';
hold <= '0';
end if;
end case;
end if;
end process;
holdoff_enable <= holdoff_enable_i and prescale;
holdoff_reset <= holdoff_reset_i and prescale;
end Behavioral;
-----
Is this new mealy-like approach correctly done?
Thanks for helping.
I'm really learning something from this!
/Preben Holm
Article: 81352Hi, I'd like to learn how OCP-IP works. Does anyone have a link showing a step-by-step example describing an IP with SystemC and its interface with OCP-IP ? thx.Article: 81353
Hi,
I am trying to implement a debug template in an EC-FPGA (LFEC20E) with
the Lattice ispTRACY IP Manager.
I am facing some problems. Maybe someone of you has experienced the same
and can lead me into the right direction.
Here are the steps I perform:
1. In the ispLEVER Project Navigator I open under TOOLS the ispTRACY IP
Manager
2. In the ispTRACY IP Manager I define the RAM depth etc. under
CUSTOMIZE, then I click GENERATE to generate the file.
3. In the CORE LINKER I can connect the signals I want to look at with
the generated I/Os of the generated template.
When clicking OK a new top level file is generated
("eval_ddr_top_test_debug.vhd")
When importing this new top level file in the Project Navigator I see
that in the new top level file there is instantiated a component
"test_debug.vhd". But this file is missing. Instead there is just a file
"test_debug_tmpl.vhd" which can only be imported as a package.
So the component is missing.
Can someone tell me what went wrong or where to find the missing file?
Rgds
Andrés
Article: 81354On Mon, 21 Mar 2005 13:01:15 -0800, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Sander Vesik wrote: >> Nial Stewart <nial@nialstewartdevelopments.co.uk> wrote: > >>>The MAC address should be unique for every piece of ehternet connectable >>>kit. > >> at least in theory. most cards support changing it because well... >> its just in a serial eeprom that can be read/written from the host. >> which is so because nobody wants to have two serial eeproms per card. > >Traditionally it was stored in ROM, and at initialization the >software driver would read the ROM and write into the >appropriate register on the ethernet controller. > >It might be that they are now in EEPROM, but I believe they are >still read/written by software, in part to support systems that >require special MAC addresses (DECNet, for one). > >I don't know if license software uses the ROM/EEPROM address, or >the one assigned to the ethernet hardware. > >-- glen Many drivers allow a user-specified address to override the programmed in one. I would imagine any licensing software uses the adddress that the driver gives (i.e. possibly modified), as otherwise it would need to know about all the different types of card hardware.Article: 81355
On 2005-03-21, Piotr Wyderski <wyderskiREMOVE@ii.uni.wroc.pl> wrote: > So I need a VHDL simulator which can read and write > data (24-bit integers) from/to a text file. The simulator I have used Savant for this purpose for a long time ago. It was not very robust against syntax errors/bugs back then, but for good code it works. Maybe it's gotten better. Somewhat praised free simulator is GHDL. You might want to check it out. Included in Debian Linux, by the way. I haven't tried it myself. Third completely free sim is FreeHDL, but when I last time checked it was quite unfinished. Of proprietary (but free) simulators, I've been quite satisfied with Symphony EDA. Works well, but is a bit slower than ModelSim/QuickHDL. Use Google to find the programs.Article: 81356
Ben Twijnstra wrote: >>but that means Xilinx has internally a PowerPC Soft Core IP? >>If they dont then could not measure the power difference :) >>I wonder why there is no information about the xilinx soft-core PowerPC at >>all? > I'm absolutely positive that IBM has produced a synthesizable PowerPC core > that Xilinx has a license for. I agree, but... >How else would they be able to verify the >functionality of the V2Pro and V4 devices? Formal verification of a non-synthesizable core? (äquivalence check, model checking, ...) Validation by simulation of a non-synthesizable core? Kolja SulimmaArticle: 81357
I do agree with Ben, there are a lot of super-PALs (or CPLDs) with JTAG capabilities. On the other hand, GALs are a very good replacement for PALs and these are still available. If you chech Lattice's website, you will find some documents about programmer support for GAL's and therefore also PAL's. Regards, Luc On Tue, 22 Mar 2005 08:23:07 GMT, Ben Twijnstra <btwijnstra@gmail.com> wrote: >Hi Gregg, > >> Hello from the Eighth Doctor >> (Apologies if this question is not group appropriate.) >> It seems my company's perenial problem with the PAL chips have sprouted >> again. The same individual that we created a something or other for, using >> a collection of PAL chips, and some normal glue logic wants us to make >> more of these things. Essentially a follow on to that thing. What it's >> supposed to do isn't the problem. Yet. It's the programming of the blank >> parts that is the problem. > >Can't you convince your colleague to use something slightly more modern than >a PAL? I see more and more manufacturers dropping support for PALs (great >pity), and PALASM is not the most user-friendly way to develop logic or >testing harnesses in. > >Especially now that (s)he is going to use multiple PALs on a board (s)he >might take a look at CPLDs (sort of a super-PAL), which have a larger >capacity for logic and registers, plus the great majority can simply be >programmed while already soldered on the board through JTAG. > >I'm professionally biased towards Altera MAX devices, but there's a whole >bunch of other CPLD vendors that offer JTAG programmability. > >Best regards, > > >BenArticle: 81358
Hallo, in a hobby-design with Spartan3-200-TQ144 I wish to use DDR-RAM (Samsung SSTL2-25, max. 400MBit/s per IO, 32 Bit, 100Pins: K4D263238). To save up DCI and VREF-lines, I declared one IO-Bank to be output only. Since I'm actually focussing on the HW, I'm unsure about wich IO-standard to select for this output-only bank (the xilinx datasheet reads a bit like "electing SSTL2 will require VREF pins, no matter of direction"). Furthermore, since this is my first PCB-layout, it'd be nice if=20 someone more experienced in PCB-design would give some hint=20 about it: 2-layer PCB, spartan on "blue", RAM on "red". Rambus on IO-Banks 1,2,3,6,7 (Bank 6 is out-only adress-Bus).=20 Nearly all rambus signals (only ~3 missing) are routed below the TQ144 chip, so there still seems to be room enough for the = power-rails outside the chip-scale on both layers. Linelen.: 15 mm .. 21 mm (except BA0,1 lines [bottom 2 horizontal blue = lines]) LineInd.: 2.2nH .. 3.3nH (if I get this Software right) www.abnuto.de/pcb1.gif I'm unsure about the importance of further thinking about the rambus. Is board-impedance matching really an issue with 20mm / max.400 mbpps? Gruss Jan BrunsArticle: 81359
Jan Bruns wrote: > Is board-impedance matching really an issue with 20mm / max.400 mbpps? no, but you will see a lot of inductive coupling in your design. Maybe you can add guard traces between you wires? Or simply spend the addtion 50$ for a multi layer board. Kolja SulimmaArticle: 81360
Hi Kolja Sulimma, > Ben Twijnstra wrote: > >>>but that means Xilinx has internally a PowerPC Soft Core IP? >>>If they dont then could not measure the power difference :) >>>I wonder why there is no information about the xilinx soft-core PowerPC >>>at all? > >> I'm absolutely positive that IBM has produced a synthesizable PowerPC >> core that Xilinx has a license for. > > I agree, but... > >>How else would they be able to verify the >>functionality of the V2Pro and V4 devices? > > Formal verification of a non-synthesizable core? (äquivalence check, > model checking, ...) > Validation by simulation of a non-synthesizable core? True - but most ASIC houses I run into prefer to do all of these, especially with larger projects - and I think that a Virtex qualifies as a 'larger' project. Let's wait what Austin says ;-) BenArticle: 81361
A second failure took place. I reset all of the ICs, disabled the cards master clock and left all of the FPGAs in the unprogrammed state. Looking around I was not able to tell if the 1MHz signal was present or not. It is so far down in the noise floor that it is virtually undetectable. I decided to start looking at wider BWs. It appears that the internal clock is not 1MHz, but much higher. Doing a sweep from 500KHz to 50MHz and comparing the peaks, the IC that is in the strange state is missing a peak at around 16-17MHz. This signal is changes part to part which I would expect for a sloppy oscillator. Again, the data sheets do not mention this. I will try and call Xilinx today and see if they can confirm that this is the internal clock.Article: 81362
Hi Jan, I like the way you've gone to all that effort to make the traces have equal length! I'm sure you've taken into account the different lengths of the signals in the lead-frames in both packages when doing this? Think about it, the electric travels about 2.54cm in 160ps. (your name sounds as though you'd prefer metric measurements! ;-)) At 400 Mbit/s each bit lasts for 2.5ns or about 40cm. How important do you think it is for all those signals to have exactly equal length? Cut yourself a little slack. FWIW, given the two layer limitation, I would connect all the RAM pins straight through the board to the nearest FPGA pins, using whatever banks I had to. (Unless you have other reasons for bank selection?) Then flood under the RAM with a ground fill, and under the FPGA with Vccint. Via the FPGA grounds straight into the ground fill under the RAM. Vcco would be a ring around the outside of the FPGA. 1uF 0402 X5R decoupling caps for Vcco, Vccint, Vccaux inside this ring. Anyway, good luck. Cheers, Syms.Article: 81363
There's a big difference between a synthesizable ASIC CPU model and an FPGA optimized CPU model. Back in 2000 I did a design study on implementing the PPC instruction set architecture. Depending upon specific hard-wired or software-emulated feature sets, and small-or-fast settings, an integer PPC subset requires between 1000-2000 LUTs and today would run at most of the speed of current FPGA optimized soft CPU cores. Jan GrayArticle: 81364
> Of proprietary (but free) simulators, I've been quite satisfied > with Symphony EDA. Works well, but is a bit slower than > ModelSim/QuickHDL. > > Use Google to find the programs. I was having a quick look a week or so ago and noticed that version 3.0 (from memory) is out soon with big performance improvements promised. This, with a top of the range new PC might be as fast as Modelsim running on a PC that's 18 months old and would be about 0.25 of the cost (in the UK). NialArticle: 81365
I too dislike the user interfaces of todays leading FPGA providers. I don't think that either A or X have a useful or productive tool. BUT, what works for me very well, is to understand the flow, and use makefiles and scripts to drive the command line tools. I have been very successful with this method. My development cycle looks like this: 1) create a deign in verilog (including verification); 2) edit ucf file; 3) run my script to create a bit file from my rtl; 4) bring up FPGA. Once in a blue moon I still start up xps (EDK) to configure an SoC. But I usually just use the tools for the basic build, and than manually edit the appropriate configuration files, and rerun gmake ... Cheers, rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 81366
I bought a Digilent Inc S3 Board, and now I'm starting to use it. The first thing I'm trying to do is implement a counter and test my Hex 2 SevSeg controller. I have put the correct FPGA en my Webpack project and have read Digilent's reference manual, but when I try to write the pinouts that digilent states, the Webpack does not accept them and clears the box automatically(E13,G13,N15,P15,R16,F13,N16). Any ideas why this could be? Thanks Jorge ----------- al912912Article: 81367
To further verify that the 16MHz is the internal clock I tried to change the temperature of the device to see how it effects the frequency and indeed it does. Just what you would expect from an RC design. I am very confident that the oscillator is the problem. I did some searching and came across an app note form 1997 that talks about the 1Mhz clock on the 3000. "The nominal frequency of this oscillator is 1 MHz with a max deviation of +25% to -10%. The clock frequency, therefore, is between 1.25 MHz and 0.5 MHz. In the XC4000 family, the 1-MHz clock is derived from an internal 8-MHz clock that also can be used as CCLK source." I have provided Xilinx with the lot codes on these parts and I am guessing that at some point the oscillator was changed to 16MHz on the 3000. I am trying more tests now to try and get other oscillators to fail.Article: 81368
Dear everybody, I have a problem on some production boards based on the Altera Cyclone FPGA. The boards have installed NIOS II CPU. The problem regards the power-on sequence because some boards are not able to power-up correctly (seems NIOS II CPU doesn't execute first operative code). The development was made on a C7 speed grade FPGA and I didn't experience such problem. The boards where the problems were detected have installed the C8 speed grade Cyclone. The power-on and reset circuitry comes from Altera's Cyclone development board. I think the problem is around the FPGA speed grade, but I was not able to find the reason. My system works at 64 MHz which is a well supported frequency by the C8 speed grade device. Did you experience my same problem ? Any tips to workaround the problem will be appreciated Best Regards /AlessandroArticle: 81369
lecroy, The oscillator itself is at a much higher frequency, and is divided down to the number listed in the data sheet. At least, we still do it that way, even today. The accuracy of this oscillator would be from 1/2 to 2X the nominal (it just isn't critical). Since this part still had paper schematics (REALLY) it is far too old for us to go look at its design. Phil is on the right track. This part did have a brownout issue (if the the voltage dropped just right, for just the right amount of time, and came back up) that would place it in a locked state that could not be recovered until the power was cycled. I solved this problem 15 years ago by using a Dallas Semi Power on Reset part to reset the power supply if it detected a glitch. The product was an optical multiplexer for then AT&T (and then Lucent). We had sold more than 100K units in three years. I think you can still buy them even today. They are used in some applications that are actually critical, so they went through an amazing battery of tests (for the audio radio channels at all US and Canadian Airports, for example). Austin lecroy7200@chek.com wrote: > To further verify that the 16MHz is the internal clock I tried to > change the temperature of the device to see how it effects the > frequency and indeed it does. Just what you would expect from an RC > design. I am very confident that the oscillator is the problem. > > I did some searching and came across an app note form 1997 that talks > about the 1Mhz clock on the 3000. > > "The nominal frequency of this oscillator is 1 MHz with a > max deviation of +25% to -10%. The clock frequency, > therefore, is between 1.25 MHz and 0.5 MHz. In the > XC4000 family, the 1-MHz clock is derived from an internal > 8-MHz clock that also can be used as CCLK source." > > I have provided Xilinx with the lot codes on these parts and I am > guessing that at some point the oscillator was changed to 16MHz on the > 3000. > > I am trying more tests now to try and get other oscillators to fail. >Article: 81370
I. Ulises Hernandez wrote: > Marc, > > Thanks for pointing me to the XCell paper, they seem to be claiming it's > OC-48 complaint... and it makes you doubt about OC-192 if they are not > shouting it from the roof tops... it could be jitter in the tx direction or > something. > > As you said, there are lots of 11.1 Gbps figures but suddenly in their last > and most recent datasheet no more 11.1Gbps, only 10.3125 Gbps... > > Regards, > Virtex-4 is not OC-192 compliant. The Sonet specifications have extremely tight specifications that are very difficult to meet with a universal transceiver. Virtex-4 is OC-48 compliant as we have the necessary margins to meet the specs due to the design needs for 10 Gbps. EdArticle: 81371
Hi, Anybody can tell me if Lattic ECP/EC FPGA devices support partial run-time reconfiguration? If yes, is there any related application note I can refer. Thanks a lot NickelArticle: 81372
Antti Lukats wrote: > In XCELL issue 52, page 19 Xilinx claims that: > > V4-PowerPC reduces power 10:1 compared to FPGA Fabric built version (of > PowerPC) > > but that means Xilinx has internally a PowerPC Soft Core IP? > If they dont then could not measure the power difference :) > I wonder why there is no information about the xilinx soft-core PowerPC at > all? > > Antti > > Yes, we have an soft version of the PowerPC 405. We used this extensively in the development of the Virtex-II Pro family in order to create and verify IP blocks, development system tools, port software and to provide early access system boards to external 3rd party developers. We were able to do this through our contract with IBM and a lot of work within Xilinx. No, there are no plans to release this as we do not have the rights to do so and the size, speed and power would make it unattractive to nearly everyone. The V-4 PowerPC 405 in comparison displaces only 672 slices, consumes 0.29mW/DMIP (0.44mW/MHz), runs up to 450 MHz and places and routes in less then a second. Just try to get a soft processor to match that. :) EdArticle: 81373
The next Thursday March 11th is in the year 2010 so I figure you mean March 24th as it says in the link :-) I hope the talk is informative (for a reasonable engineer). "Vaughn Betz" <no_spam@altera.com> wrote in message news:4KN%d.6327$nK.608185@news20.bellglobal.com... > I'll be presenting a Net Seminar on both FPGA and HardCopy II power this > Thursday, March 11, at 11 am Pacific Standard Time. It'll be a technical > presentation, so I believe it'll be of interest to most of the people on > this group who have been following the power debate for the last few months. > > In this talk, I'll: > > - give an overview of how to analyze power accurately > - describe the steps we took to optimize total device power (dynamic + > static + IO) in Stratix II > - provide both estimator/specification-based and measured power comparisons > between Stratix II and Virtex 4 > - describe the power you can expect from Altera's HardCopy II structured > ASICs (hint: low :). > > See http://www.altera.com/education/net_seminars/current/ns-fpgapower.html > for details and to register (registration is free of course!). > > Vaughn Betz > Altera > [v b e t z (at) altera.com] > >Article: 81374
Hi, Maybe a excessive power-on current? Dan.
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