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 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. 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. Hope this helps, Subroto Datta Altera Corp. "John Rible" <jrible@sandpipers.com> wrote in message news:cuu51002pte@enews4.newsguy.com... > I'm using Verilog under Quartus 4.1sp2 to build a model of a custom part > that has 25 identical (more-or-less) sub-modules, each with a small rom. > Working bottom-up I built and tested the submodule: no problems. I used > the wizard to build the rom code, specifing a .hex file for > initialization. > > I then created the top module with the 25 instances of the rom, but could > not find any way to specify 25 UNIQUE .hex files for the roms. An Altera > service request was not helpful except to get to the essence of the > problem. Then I built a 4 sub-module test model, and, by hand, created 4 > differently named copies of the rom module, renaming the .hex file > specified in it. > > That worked, but there has to be a simpler way! Question 1: what is it? > > Some of the sub-module's outputs, connected only to other sub-modules, are > the inverted contents of a register. I got the correct values for the > sub-module test, but the inverters were 'hidden' by synthesis, even when I > specified 'firm' hierarchy boundaries. The execution of the custom part > assumes the inversion, and I've got to include it. Question 2: How? > > Thanks, > JohnArticle: 79251
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: 79252
glen herrmannsfeldt wrote: > Austin Lesea wrote: > (big snip) > > > Is comparing our middle speed grade with > > their fastest honest? Well, if that is the only thing they can get > > their hands on, perhaps it is. Would it be better to compare their > > slowest with our slowest? Who would be excited about that? > > I wonder what fraction of FPGA designs are not very speed > sensitive. I used to wonder about that in TTL days, building > digital clocks (60Hz for the fastest signals) out of 30MHz TTL > chips. > > 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. Like has seemingly occured with microprocessors, will there come a time when FPGA's are fast enough for all but a small number of of fringe applications? Except for the gamers, you don't hear people talking about needing a faster CPU anymore - they are "fast enough." Before the vendors jump all over me, I'm not saying that FPGA's have reached that point yet. And yes I realize that there is still plenty of innovation that they can do on their side. And each one of those responses would miss my point. We push our FPGA's pretty hard where I work, and in the past, have always come up with a list of things that we want or need for the next generation device. But when Xilinx came around asking their thousand questions about what what they can improve on over V4 for the next gen device, our suggestion list was very short. I am most certainly not saying innovation is over when some engineers at a startup can't come up with really good ideas for next gen parts. I'm just saying that from where we sit, the FPGA's seem to be approaching "good enough." Not there yet, but approaching. I'm sure we'll want a 40 Gbps SERDES (with CDR) on every I/O pin someday, and we'll want to run several levels of logic at 1 GHz or more. But the wish list is pretty short compared to what it used to be - and I'm willing to wait a number of years for it to come true (where as in the past, there's usually been something that we needed immedately and had to "design around" the current architecture). 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? > For the most part, I don't find this discussion very useful. > We all know about marketing departments, and having engineers > argue this doesn't cause me to look favorable on their company > or products. While I agree with Glen that the quibbling about power was highly annoying, especially when everyone knew they were dealing with pre-release numbers and products that the vendors know are not final, after putting all the information through the FUD filter, I did come away with a better understanding of the issues involved, helped somewhat by the (probably rushed) update of the S2 power numbers. Have fun, MarcArticle: 79253
Antti Lukats wrote: > > Hi Rudi, > > I think a bus bridgeing component for EDK can not be > implemented fully as netlist at all, not with current > state of the tools, and maybe never. Why not ? > So at least one file of the ip core should be HDL source > the remaining can be netlist. The parameters are handled > in the HDL part of of the core. > > Antti The only issue is the parameter handling, which currently I guess are synthesized away. One way around that would be to make the parameters real wires and have the user specify constant values on those wire. That would of course defeat the whole purpose of EDK and being able to do auto-config. Unless of course we add another wrapper on top of the IP Core to hide this ... what a mess ! rudi ============================================================= Rudolf Usselmann, ASICS World Services, http://www.asics.ws Your Partner for IP Cores, Design, Verification and SynthesisArticle: 79254
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: 79255
Hello all, I want to signal 5 years of notes of Electronic Engineering at the University of Rome Tor Vergata proposed to you in the shape of questionnaire with answers, I spend really much effort at that time and also now for the publication on Internet, I would be happy if these notes could be of aid to other persons, you can find them at the link: http://www.etantonio.it/EN/Universita/Universita.aspx and for the electronics in particular: http://www.etantonio.it/EN/Universita/3anno/ElettronicaApplicata/index.aspx http://www.etantonio.it/EN/Universita/4anno/DispositiviElettronici/index.aspx http://www.etantonio.it/EN/Universita/4anno/Microelettronica/index.aspx http://www.etantonio.it/EN/Universita/4anno/Optoelettronica/index.aspx http://www.etantonio.it/EN/Universita/5anno/CircuitiIntegratiMicroonde/index.aspx http://www.etantonio.it/EN/Universita/5anno/ElettronicaMicroonde/index.aspx http://www.etantonio.it/EN/Universita/5anno/SintesiSistemiIntegratiComplessi/index.aspx and naturally my Thesis: http://www.etantonio.it/EN/Universita/Tesi/index.aspx if you found any inaccuracy or error please let me know... Thanks for the attention Eng Antonio D'Ottavio postmaster@etantonio.it www.etantonio.it/EN/Article: 79256
"Philipp" <carlsberg@gmx.at> wrote in message news:37easgF56o3utU1@individual.net... > >> but.. in your case as you are doing some FSL stuff that may stall the >> microblaze >> so that may be your problem. > > Yeah but the thing I dont understand is that I can execute 8000 > instructions without any trouble and then suddenly it just overwrites me > an arbitrary register by executing a simple addition instruction. And with > a dummy function it works.... weird > I had a funky problem where I traced it back to a misplaced BASEADDRESS for the xilmfs library specification in the "system".mss file. That BASEADDRESS was stepping on code or data placed in SRAM by the linker. The symptom was that if I commented out what was essentially a nop variable assignment, a subsequent routine would bomb out. I don't know why this slab of memory is located via a hardcoded parameter, and not automatically off the heap Oh well, this is probably not your problem. BTW, this was for a PPC. Cheers -NewmanArticle: 79257
Phil Tomson wrote: > Here's the error: > > Analyzing Entity <csvm> (Architecture <synth_csvm>). > ERROR:Xst:829 - C:/phil/vhdl/svm/../fix_std.vhd line 1382: Constant Value > expected for Generic 'U'. > > > Here's the offending line: > Copy_V(F, N, overflow, rounding); The error is about a generic. The line above does not contain a generic. Seems to me that the line number in your error message is wrong. Look in your code and try to locate where you declare and/or use generic U (in an entity declaration or component instantiation). Paul.Article: 79258
Hi, I am desging an master interface for 64-bit PLB.when i am not locking the bus and if i get a Mn_rearbitrate from the slave ,and am de-asserting and asserting the request after one clk.But it seems like the arbiter is not arbitrating the request from the me(master) after it got an M1_rearbitrate(never i get the bus , after that), how i can i proceed further to do my data transfer. thanx, mack.Article: 79259
In article <cuusld$spu$1@voyager.news.surf.net>, Paul Uiterlinden <no@spam.nl> wrote: >Phil Tomson wrote: >> Here's the error: >> >> Analyzing Entity <csvm> (Architecture <synth_csvm>). >> ERROR:Xst:829 - C:/phil/vhdl/svm/../fix_std.vhd line 1382: Constant Value >> expected for Generic 'U'. >> >> >> Here's the offending line: >> Copy_V(F, N, overflow, rounding); > >The error is about a generic. The line above does not contain a generic. >Seems to me that the line number in your error message is wrong. > >Look in your code and try to locate where you declare and/or use generic >U (in an entity declaration or component instantiation). > I did a `grep -i generic *.vhd` and nothing comes up in that code (there is a testbench that has some, but it's not included in the ISE project). That's what's strange about the error. It would be nice if the Xilinx tools could synthesize a fixed point package - so far I've tried two synthesizable (with other tools) fixed point packages and it chokes on both, but for different reasons. PhilArticle: 79260
Thank you to everyone (especially Allan and Huub) you assistance is most appreciated. I now understand where I have gone wrong and my model has been corrected and now operates as expected. Once again thanks SimonArticle: 79261
First of all AN on the board AN is low active , so if you want to turn off the 7 segment you have to put the respective AN to 0. Then for the counter I will not do a reset condition , i would put 1 bit less in the counter and by overflow it will come back to zero without using a comparator And finnaly I would have use a case choice better than en elsif conditionnal so the new code should be : entity Display is Port ( clk : in std_logic; rst : in std_logic; d0 : in integer range 0 to 9; d1 : in integer range 0 to 9; d2 : in integer range 0 to 9; d3 : in integer range 0 to 9; seven_seg : out std_logic_vector(6 downto 0); AN3 : inout std_logic; AN2 : inout std_logic; AN1 : inout std_logic; AN0 : inout std_logic); end Display; architecture Behavioral of Display is component countdecoder is port( count: in integer range 0 to 9; seven_seg : out std_logic_vector(6 downto 0)); end component; signal count : integer range 0 to 9; signal CTR : std_logic_vector(11 downto 0); begin -- make a copy of the decoder decoder1: countdecoder port map(count => count, seven_seg => seven_seg); Display_left_to_right: process(rst,clk) begin if rst = '1' then count <= 0; AN3 <= '0'; AN2 <= '1'; AN1 <= '1'; AN0 <= '1'; elsif clk'event and clk = '1' then if (ctr = "000000000000") then case (AN3 & AN2 & AN1 & AN0) is when "0111" => AN3 <= '1'; count <= d3; AN2 <= '0'; when "1011" => AN2 <= '1'; count <= d2; AN1 <= '0'; when "1101" => AN1 <= '1'; count <= d1; AN0 <= '0'; when "1110" => AN0 <= '1'; count <= d0; AN3 <= '0'; when others => AN3 <= '0'; AN2 <= '1'; AN1 <= '1'; AN0 <= '1'; count <=d3; end case; end if; ctr <= ctr + "000000000001"; end if; end process Display_left_to_right; end Behavioral; Try this , I couldn't try because I haven't got your countdecoder You could also do: entity Display is Port ( clk : in std_logic; rst : in std_logic; d0 : in integer range 0 to 9; d1 : in integer range 0 to 9; d2 : in integer range 0 to 9; d3 : in integer range 0 to 9; seven_seg : out std_logic_vector(6 downto 0); AN3 : inout std_logic; AN2 : inout std_logic; AN1 : inout std_logic; AN0 : inout std_logic); end Display; architecture Behavioral of Display is component countdecoder is port( count: in integer range 0 to 9; seven_seg : out std_logic_vector(6 downto 0)); end component; signal count : integer range 0 to 9; signal CTR : std_logic_vector(11 downto 0); begin -- make a copy of the decoder decoder1: countdecoder port map(count => count, seven_seg => seven_seg); Display_left_to_right: process(rst,clk) begin if rst = '1' then count <= d3; AN3 <= '0'; AN2 <= '1'; AN1 <= '1'; AN0 <= '1'; elsif clk'event and clk = '1' then case (ctr(11 downto 8)) is when "0111" => AN3 <= '1'; count <= d3; AN2 <= '0'; when "1011" => AN2 <= '1'; count <= d2; AN1 <= '0'; when "1101" => AN1 <= '1'; count <= d1; AN0 <= '0'; when "1110" => AN0 <= '1'; count <= d0; AN3 <= '0'; when others => end case; ctr <= ctr + "000000000001"; end if; end process Display_left_to_right; end Behavioral; But in this case the refresh frequency should be higher so you could need to add some bit to your counter (4) the case take always be on the MSB of the counter "fpgawizz" <bhaskarstays@yahoo.com> a écrit dans le message de news: efe76377b421bb9f032000801ca0c7a2@localhost.talkaboutelectronicequipment.com... > her is my code > entity Display is > Port ( clk : in std_logic; > rst : in std_logic; > d0 : in integer range 0 to 9; > d1 : in integer range 0 to 9; > d2 : in integer range 0 to 9; > d3 : in integer range 0 to 9; > seven_seg : out std_logic_vector(6 downto 0); > AN3 : inout std_logic; > AN2 : inout std_logic; > AN1 : inout std_logic; > AN0 : inout std_logic); > end Display; > > architecture Behavioral of Display is > component countdecoder is > port( count: in integer range 0 to 9; > seven_seg : out std_logic_vector(6 downto 0)); > end component; > > signal count : integer range 0 to 9; > signal CTR : std_logic_vector(12 downto 0); > begin > -- make a copy of the decoder > decoder1: countdecoder port map(count => count, seven_seg => seven_seg); > > Display_left_to_right: process(rst,clk) > begin > if rst = '1' then > count <= 0; > AN3 <= '0'; > AN2 <= '0'; > AN1 <= '0'; > AN0 <= '0'; > elsif clk'event and clk = '1' then > if (ctr = "0000000000000") then > if AN3 = '0' then > AN3 <= '1'; > count <= d3; > AN0 <= '0'; > elsif AN2 = '0' then > AN2 <= '1'; > count <= d2; > AN1 <= '0'; > elsif AN1 = '0' then > AN1 <= '1'; > count <= d1; > AN2 <= '0'; > elsif AN0 = '0' then > AN0 <= '1'; > count <= d0; > AN3 <= '0'; > end if; > end if; > ctr <= ctr + "0000000000001"; > if (ctr > "1000000000000") then > ctr <= "0000000000000"; > end if; > > end if; > end process Display_left_to_right; > > end Behavioral; > > The component is a decoder that just spits out data for various integer > input values. the CTR is to delay the process block so the segments can be > refreshed at a slower rate.I could have used a slower clock in my process > statement i guess. > > pls advise > >Article: 79262
Can one use a CC_LC (regional clock) to drive the global clock tree via a BUFG or IBUFG primitive? I assume this is a bad design practice, because CC_LC are 'external' pins, whereas GC pins are located near the center of the die... Do I risk a high clock skew resulting in poor synthesized frequency? Regards, SteveArticle: 79263
On Tue, 15 Feb 2005 13:32:21 +0100, "Piotr Wyderski" <wyderskiREMOVE@ii.uni.wroc.pl> wrote: >Leon Heller wrote: > >> You could amplify it with a MMIC (like the MInicircuits ERA-1) > >The original signal has about 6Vpp and the output is taken from >a divider connected to an emitter follower, so it is enough to >decrease attenuatnion. 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. 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. Careful design (e.g. separate digital and analog ground planes) is important but even so, a lower edge speed may be better. You will have to make the right compromise between low jitter (fast edge) and sine purity, according to the purpose of your design. - BrianArticle: 79264
Hello I have implemented a FSL core for the Microblaze processor. It is a very easy test programm, and now I wanna try to use chipscope to take a look at the internal registers of my Core. I think this is achivable with Chipscope, so is there somewhere a useful tutorial which explains me step by step what I have to do to be able to read out data from my core? Would be very thankful for usefull tips Best Wishes ClemensArticle: 79265
The file lib/version.txt has the version information, which you can use to extract the version. The simplest way I'd suggest is to set an environment variable (something like SYNPLIFY_PRO_VERSION) when you set up the environment (PATH etc) for synplify_pro. HTH, Jim jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chips <zhangpei@gmail.com> wrote in message news:1108511768.743405.222520@g14g2000cwa.googlegroups.com... > Is there anyway to know synplify_pro version through tcl command or > variable? Since its 8.0 has some major difference than old version in > false path constraints. I just want to load those automatically > generated constraints if synplify_pro version is greater than 8.0. > > thanks, > > Pei >Article: 79266
Steve wrote: > Can one use a CC_LC (regional clock) to drive the global clock tree via a BUFG or IBUFG primitive? > > I assume this is a bad design practice, because CC_LC are 'external' pins, whereas GC pins are located near the center of the die... > Howdy Steve, It is possible to take a generally routed signal and put it on a global clock. And as you suspected, it isn't recommended, although not for the reasons you list. The main reason for having the global clock inputs come from certain pins (and local clock inputs too, for that matter) is so that there is known amount of delay between the input pin and the resources it will be driving. Having a known amount of delay allows you to control the timing between that clock and the other I/O pins in the device (or region). Here are the two main examples: 1. If the clock has a known (fixed) phase relationship with other signals on the board and is responsible for clocking those signals into the FPGA, you really want to use a dedicated clock input. 2. If there are bits being clocked out of the FPGA that need to have a fixed relationship with the *input* phase of the clock, you want to use a dedicated clock input. 3. Virtex-4 has introduced a third reason: global clocks are routed differentially, so if you want low jitter, use them. You'll notice that the wording for each of those uses the word "want." That is the one thing that my coworkers and I have always loved about Xilinx - they don't keep you from doing most things you want to do, even if you want to do it in a way that isn't generally advisable. So, going back to my very first sentence of this post, it is possible to use the local routing over to a global clock net. It is also possible to nail this routing down so that it doesn't change everytime you do a P&R - and when you nail it down, you now have a fixed (although large) delay. Figure out what that delay is (using FPGA editor to get a starting point) and feed the clock into a DCM, which you'll use to dial out all that large delay. Or with V4, you can dial the delay into the ISERDES, either for the "clock input", or for the data bits, and get the same result. > Do I risk a high clock skew resulting in poor synthesized frequency? I'm not sure what you are asking here. Are you referring to using a DCM? Or simply that the signal on the global clock net is some sort of "resynthesized" version of the clock that came into the device originally? Regardless, the answer is that if you use global (or local) dedicated clock resources, you won't have skew. In the above paragraphs, I explained how you'll have extra delay before get on the clock net, but you shouldn't have skew. Good luck, MarcArticle: 79267
Check the following answer record http://tinyurl.com/538ve HTH, Jim jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chips "pnc" <mail2pnc@gmail.com> wrote in message news:1107558246.051981.296420@l41g2000cwc.googlegroups.com... > Does anybody know where I can download/source Orcad Capture (schematic > ) > and Layout ( footprints ) library parts for Xilinx Spartan 3 > FPGA's, particularly XC3S400 in PQ208 package from the net? > I'd prefer a freebie source but am will to use a 3rd party vendor > other than Cadence. > > Thanks for any leads/advice. > > -pnc >Article: 79268
Like I have nothing to do at this time I have made a last, simple and optimized "display controller" that should fit to your application, it saves 40% of slice ( lol 40% sound greater than 9slices :) the refresh time is 1 cylce less than before (but over 4000cycles I think it don't really care for what you want to do) the reset became synchronous but don't really need of reset for AN and count. here is the file: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; -- Uncomment the following lines to use the declarations that are -- provided for instantiating Xilinx primitive components. --library UNISIM; --use UNISIM.VComponents.all; entity Display is Port ( clk : in std_logic; rst : in std_logic; d0 : in integer range 0 to 9; d1 : in integer range 0 to 9; d2 : in integer range 0 to 9; d3 : in integer range 0 to 9; seven_seg : out std_logic_vector(6 downto 0); AN3 : inout std_logic; AN2 : inout std_logic; AN1 : inout std_logic; AN0 : inout std_logic); end Display; architecture Behavioral of Display is component countdecoder is port( count: in integer range 0 to 9; seven_seg : out std_logic_vector(6 downto 0)); end component; signal count : integer range 0 to 9; signal CTR : std_logic_vector(13 downto 0); begin -- make a copy of the decoder decoder1: countdecoder port map(count => count, seven_seg => seven_seg); Display_left_to_right: process(rst,clk) begin if rising_edge(clk) then if rst='1' then ctr <= (others=>'0'); count <= 0; AN3 <= '0'; AN2 <= '0'; AN1 <= '0'; AN0 <= '0'; else ctr <= ctr + "00000000000001"; case (ctr(13 downto 12)) is when "00" => count <= d3; AN3 <= '0'; AN2 <= '1'; AN1 <= '1'; AN0 <= '1'; when "01" => count <= d2; AN3 <= '1'; AN2 <= '0'; AN1 <= '1'; AN0 <= '1'; when "10" => count <= d1; AN3 <= '1'; AN2 <= '1'; AN1 <= '0'; AN0 <= '1'; when "11" => count <= d0; AN3 <= '1'; AN2 <= '1'; AN1 <= '1'; AN0 <= '0'; when others => end case; end if; end if; end process Display_left_to_right; end Behavioral; "KCL" <kclo4_NO_SPAM_@free.fr> a écrit dans le message de news: 4213188f$0$19402$8fcfb975@news.wanadoo.fr... > First of all AN on the board AN is low active , so if you want to turn off > the 7 segment you have to put the respective AN to 0. > > Then for the counter I will not do a reset condition , i would put 1 bit > less in the counter and by overflow it will come back to zero without > using a comparator > > And finnaly I would have use a case choice better than en elsif > conditionnal > > so the new code should be : > > entity Display is > Port ( clk : in std_logic; > rst : in std_logic; > d0 : in integer range 0 to 9; > d1 : in integer range 0 to 9; > d2 : in integer range 0 to 9; > d3 : in integer range 0 to 9; > seven_seg : out std_logic_vector(6 downto 0); > AN3 : inout std_logic; > AN2 : inout std_logic; > AN1 : inout std_logic; > AN0 : inout std_logic); > end Display; > > architecture Behavioral of Display is > component countdecoder is > port( count: in integer range 0 to 9; > seven_seg : out std_logic_vector(6 downto 0)); > end component; > > signal count : integer range 0 to 9; > signal CTR : std_logic_vector(11 downto 0); > begin > -- make a copy of the decoder > decoder1: countdecoder port map(count => count, seven_seg => seven_seg); > > Display_left_to_right: process(rst,clk) > begin > if rst = '1' then > count <= 0; > AN3 <= '0'; > AN2 <= '1'; > AN1 <= '1'; > AN0 <= '1'; > elsif clk'event and clk = '1' then > if (ctr = "000000000000") then > case (AN3 & AN2 & AN1 & AN0) is > when "0111" => > AN3 <= '1'; > count <= d3; > AN2 <= '0'; > when "1011" => > AN2 <= '1'; > count <= d2; > AN1 <= '0'; > when "1101" => > AN1 <= '1'; > count <= d1; > AN0 <= '0'; > when "1110" => > AN0 <= '1'; > count <= d0; > AN3 <= '0'; > when others => > AN3 <= '0'; > AN2 <= '1'; > AN1 <= '1'; > AN0 <= '1'; > count <=d3; > end case; > end if; > ctr <= ctr + "000000000001"; > > > end if; > end process Display_left_to_right; > > end Behavioral; > > Try this , I couldn't try because I haven't got your countdecoder > You could also do: > entity Display is > Port ( clk : in std_logic; > rst : in std_logic; > d0 : in integer range 0 to 9; > d1 : in integer range 0 to 9; > d2 : in integer range 0 to 9; > d3 : in integer range 0 to 9; > seven_seg : out std_logic_vector(6 downto 0); > AN3 : inout std_logic; > AN2 : inout std_logic; > AN1 : inout std_logic; > AN0 : inout std_logic); > end Display; > > architecture Behavioral of Display is > component countdecoder is > port( count: in integer range 0 to 9; > seven_seg : out std_logic_vector(6 downto 0)); > end component; > > signal count : integer range 0 to 9; > signal CTR : std_logic_vector(11 downto 0); > begin > -- make a copy of the decoder > decoder1: countdecoder port map(count => count, seven_seg => seven_seg); > > Display_left_to_right: process(rst,clk) > begin > if rst = '1' then > count <= d3; > AN3 <= '0'; > AN2 <= '1'; > AN1 <= '1'; > AN0 <= '1'; > elsif clk'event and clk = '1' then > case (ctr(11 downto 8)) is > when "0111" => > AN3 <= '1'; > count <= d3; > AN2 <= '0'; > when "1011" => > AN2 <= '1'; > count <= d2; > AN1 <= '0'; > when "1101" => > AN1 <= '1'; > count <= d1; > AN0 <= '0'; > when "1110" => > AN0 <= '1'; > count <= d0; > AN3 <= '0'; > when others => > > end case; > > ctr <= ctr + "000000000001"; > > > end if; > end process Display_left_to_right; > > end Behavioral; > > > > But in this case the refresh frequency should be higher so you could need > to add some bit to your counter (4) the case take always be on the MSB of > the counter > > > "fpgawizz" <bhaskarstays@yahoo.com> a écrit dans le message de news: > efe76377b421bb9f032000801ca0c7a2@localhost.talkaboutelectronicequipment.com... >> her is my code >> entity Display is >> Port ( clk : in std_logic; >> rst : in std_logic; >> d0 : in integer range 0 to 9; >> d1 : in integer range 0 to 9; >> d2 : in integer range 0 to 9; >> d3 : in integer range 0 to 9; >> seven_seg : out std_logic_vector(6 downto 0); >> AN3 : inout std_logic; >> AN2 : inout std_logic; >> AN1 : inout std_logic; >> AN0 : inout std_logic); >> end Display; >> >> architecture Behavioral of Display is >> component countdecoder is >> port( count: in integer range 0 to 9; >> seven_seg : out std_logic_vector(6 downto 0)); >> end component; >> >> signal count : integer range 0 to 9; >> signal CTR : std_logic_vector(12 downto 0); >> begin >> -- make a copy of the decoder >> decoder1: countdecoder port map(count => count, seven_seg => seven_seg); >> >> Display_left_to_right: process(rst,clk) >> begin >> if rst = '1' then >> count <= 0; >> AN3 <= '0'; >> AN2 <= '0'; >> AN1 <= '0'; >> AN0 <= '0'; >> elsif clk'event and clk = '1' then >> if (ctr = "0000000000000") then >> if AN3 = '0' then >> AN3 <= '1'; >> count <= d3; >> AN0 <= '0'; >> elsif AN2 = '0' then >> AN2 <= '1'; >> count <= d2; >> AN1 <= '0'; >> elsif AN1 = '0' then >> AN1 <= '1'; >> count <= d1; >> AN2 <= '0'; >> elsif AN0 = '0' then >> AN0 <= '1'; >> count <= d0; >> AN3 <= '0'; >> end if; >> end if; >> ctr <= ctr + "0000000000001"; >> if (ctr > "1000000000000") then >> ctr <= "0000000000000"; >> end if; >> >> end if; >> end process Display_left_to_right; >> >> end Behavioral; >> >> The component is a decoder that just spits out data for various integer >> input values. the CTR is to delay the process block so the segments can >> be >> refreshed at a slower rate.I could have used a slower clock in my process >> statement i guess. >> >> pls advise >> >> > >Article: 79269
Kevin Neilson wrote: > There was a thread recently about how to protect IP, and one respondent said > that it is too much trouble to worry about protecting IP and a better model > is to just sue anybody that steals it. This seemed perhaps naive since > there are places where IP rights are not respected and attempts to sue will > probably be fruitless. Here is an excerpt from an article in the NY Times > that illustrates this: > > > "The Chinese are adept at copying and quite loose in their interpretation of > intellectual property rights. One of Mr. Fishman's more striking examples is > the auto industry, which looms large in China's economic plans. American and > Japanese companies spend $1 billion to $2 billion to develop a new car. The > Chinese, by forcing foreign car companies to form joint ventures with their > companies and to share their technology in order to enter China, hope to > leapfrog over those kinds of development costs. > Foreign companies, salivating at the thought of 100 million Chinese > customers, cannot stop themselves from signing on the dotted line. > Sometimes, rude surprises await. At the 2003 Shanghai auto show, G.M. > executives unveiled a new $9,000 small family van, only to discover an > identical vehicle, priced at $6,000, at a Chinese booth in the same row. The > clone was made by Chery, a Chinese company owned in part by Shanghai Auto, > G.M.'s joint-venture partner. " As you outlined : forget IP. Konfuzius said 2k years ago that copying the master is the way to become a master yourself. This is it. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 79270
Hi, Let see if I got this right. You have two MicroBlazes and the bram blocks. I assume that the bram blocks are shared as the original question ask about. If the uses one port each from each BRAM there is no arbitration since each bus only have one master (one of the MicroBlazes). They will share the whole memory range 0x00000000 - 0x00007fff. So this is easily handled in the XPS. Göran Elinore wrote: > i like this 'great' flexibility in FPGA. In this context, i dare to > make more 'what if' questions (to me, to others).... > > What if we have 2 microblazes (uBLAZE0, uBLAZE1) with BRAM0 and BRAM1, > respectively. Suppose BRAM0 ranges 0x00000000 - 0x00003ffff and BRAM1 > ranges 0x00004000 - 0x00007ffff. The uBLAZE0 wanna access BRAM1 using > shared variable so that programmar see 2 BRAMs as one big global > memory. Then problem will be bus ( memory access ) arbitration. So we > may need a special hardware. Writing an application code will be uneasy > as well, because we will need only one main routine. How can we utilize > xilinx-provided design resources to do those? This seems to be very > hard but interesting ...... >Article: 79271
Does anyone have any idea how i can generate the UCF required for an RPM without manually running the floorplanner? (so i can create the RPM from a makefile) the floorplanner does not apparently have a "batch mode" despite a reference to a <script_file> in the help - which is apparently not supposed to be there! I've got a hierarchical design builtup of many sub-blocks implemented as RPMs, so for each design change i need to rebuild the RPMs and recreate the full chip. A nightmare if i have to run the floorplanner interactively! Surely there is some wat to do this? a0-0bArticle: 79272
It's in the center of the center column. Regards, -Trevor bob wrote: > When designing for partial reconfiguration, the ICAP port has to be into the fixed part of the design. > > ok, but where is it in the xc4vlx60? > > at the bottom of central column?Article: 79273
Paul, I agree. Austin Paul Leventis wrote: >> -snip- > > > Power supply design is not my forte. But yes, startup currents are > complicated and I'm not sure how much I'd trust any one scope shot. > What order do you power up the various power supplies on the chip (it > changes things)? What temperature/voltage are you testing at? What > point on the process curve is the chip under test? > > Rate of ramp up in the power supply is a good example -- if you have a > supply that can supply infinite current immediately, you *will* see a > "spike". But it's likely the result of charging of board caps and chip > caps, and if you use a supply with less capacity, it will just take > longer to ramp up to full Vcc. Capacitive "spikes" are not really an > issue so long as the board/chip powers up to Vcc within the spec'ed > ramp time. > > Contention-based power-up cannot be overcome with time. If you do not > supply the necessary current, Vcc never reaches the proper value and > the chip does not power up. This is the type of "in-rush current" I > think we're debating here. > > It's easy to design around an "in-rush current" by just using the right > size power supply. > > Getting rid of contention-based start-up currents in the FPGA require > that we stage all the various initialization logic the right way, etc. > Not rocket science, but there are a number of details to get right. > > Regards, > > Paul Leventis > Altera Corp. >Article: 79274
Glen, Well, here is something useful: suppose I told you that with decreasing geometries, the models are getting both faster, leakier, AND slower, and less leaky? This brings up an interesting question, what if the next product had two extra speed grades SLOWER that the slowest? Perhaps leakage grades as well? Basically this is the implication of designing with the ever increasingly small geometries: some transistors are faster, but some will be slower, and the process control will be more difficult. For all those who do not need the speed, one could offer lower cost parts, as well as offer four (or five) more speed grades at an increasing premium. Sort of like, if you get lemons, make lemonade. The issue right now is the sales force freaks out when they hear that the next generation is both FASTER, AND SLOWER (it can be both, as it turns out). But I agree with you, that not everyone needs the fastest part. A survey of system clock speeds was quite revealing: big use at 33 MHz, 66 MHz, 100 MHz, 155 MHz, with a decreasing tail past 200 MHz. Funny thing, all these frequencies are "magic" and coincide with PCI, SONET/SDH, SDRAM, etc. No magic at all? Austin glen herrmannsfeldt wrote: > Austin Lesea wrote: > (big snip) > >> The devil is in the details: is a static power reduction at 25C an >> improvement? Yes, and No. Is comparing our middle speed grade with >> their fastest honest? Well, if that is the only thing they can get >> their hands on, perhaps it is. Would it be better to compare their >> slowest with our slowest? Who would be excited about that? > > > I wonder what fraction of FPGA designs are not very speed sensitive. I > used to wonder about that in TTL days, building > digital clocks (60Hz for the fastest signals) out of 30MHz TTL chips. > > 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. > > For the most part, I don't find this discussion very useful. > We all know about marketing departments, and having engineers > argue this doesn't cause me to look favorable on their company or products. > > -- glen >
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