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
Christopher Cole <cole@scoob.coledd.com> wrote: >The two versions of the Jungo windrvr drivers I was trying were: >http://www.jungo.com/download/WD801LN.tgz >and >http://www.jungo.com/download/WD702LN.tgz >Has anyone gotten these to compile under 2.6.16 or later? >It appears that Jungo is behind on their Linux support - windrvr >does not compile nicely for 2.6.16... it compiled fine in 2.6.15. The >root of the problem is the dynamic nature of the Linux kernel - things >change rapidly within the kernel source from release to release that >break drivers that are not an integral part of the kernel. I think Rapid changes in kernel interface is something that is avoided within bsd operating systems (freebsd, netbsd, openbsd) due more conservative code acceptence policy.. Should jungo.com ever try it ;)Article: 101526
Thanks Kolja, I have known that LEDs are actually bidirectional, but the links pointed out are great! fortunatly I aldready have my LED wired up to FPGA so that it can support the "LED sensor" mode so I defenetly will at leat try it out AnttiArticle: 101527
Jim Granville schrieb: > Antti Lukats wrote: > > "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag > >> Most obvious is to extend to a BiColour LED, Driven from 2 pins, so > >>that you can generate : Pure RED, Modulated RED (OE), Pure GREEN, > >>Modulated GREEN (OE) and Colour Modulated (PWM %R/100-% G) > >>Control lines are : R, R.oe, G, G.oe > >> > > > > dual color SMD led costs 10 times as much as single color and the layout > > isnt so standard and I have some pre-series PCBs with only one LED > > already. Sure dual color LED would have more possibilities for visual > > effects > > But costs a tiny fraction of the PCB / FPGA price, which is > what actually matters ? > dual color LED is 1.4% of the FPGA price and about 80% of the PCB price (PCB quoted in 10k qty) but well yes its still a tiny factor > >> My preferred modulation is PDM (Rate Multiplier), rather than PWM : PDM > >>uses the least resource in CPLDs, and filters better in DAC applications. > >> > > > > could you elaborate on this? I had delta-sigma DAC already on my list > > that is pulse density modulation - but you are referring to something else? > > It is probably the same thing, if your delta-sigma is PDM. > I am used to delta-sigma having a feedback loop of some sort, so I avoid > that term. > The PDM we use is the same as the venerable Rate Multipliers > ( 4089, 4527 IIRC) and they use one PT per resolution bit. > PWM compares need two, unless hand-coded. thanks for the part numbers - they are so venerable that google has trouble finding the datasheets, but st.com has them online and no the PDM (as in 4089) is not same as delta-sigma, so I will possible write the 4089 in VHDL just for the demo > >> Also not on your list, is a RC5 / manchester Encoded LED modulate. > >>Target the std IR-Remote Receivers, perhaps with an IR led in Parallel > >>if the RED energy is too low to activate a NearBy - StdIR RX unit. > >> > >> That allows actual BIT serial (status flags) info to be sent, into a > >>simple receiver. > >> there is a user slot with 6 FPGA pins so the IR thing should got there > >> One-Wire encoding is another way to send Freq tolerant information, > >>in an easily decoded manner. > >> One-Wire (as per dallas 1-wire) is does depend on known frequency, it is not fully self-adjusting (and can not be) > > > > Actually one-wire comm requires known frequency reference better than > > I can count for, also in my requirements was no other interface (than LED) > > You would use optical pickup, so are outside the "Mk1 EyeBall", but the > functions can be stacked on the LED. > One wire systems are usually PWM coded, so autobaud ? > 1-wire (a dallas) are not autobaud, many uart on one wire are autobauding > > Just to have people a way to 'seeing is beliving' want to test > > this or that, download this, when LED blinks then it is signal > > that this or that works - in real hardware. > > Always a good idea. > > -jgArticle: 101528
hi, i want to write a verilog module for a 32 channel MUX with data width of 8. following is the module i wrote and it compiles successfully. =============================================================================== `timescale 1ns / 1ps module mux(data_out, data_in[0:31], sel, en, reset); parameter data_width = 8; parameter zbus = 8'bz; parameter zerobus = 8'b0; output[data_width-1:0] data_out; input[data_width-1:0] data_in; input en, reset; input[4:0] sel; reg[data_width-1:0] data_selection; assign data_out = (!en) ? ((!reset) ? zerobus : data_selection ): zbus; always @ (data_in, sel) begin data_selection = data_in[sel]; end endmodule ====================================================================== however im experiancing some difficulties in writing the test bench for it. i've wrote the following but it does not compile. ======================================================================= `timescale 1ns / 1ps //////////////////////////////////////////////////////////////////////////////// // Company: // Engineer: // // Create Date: 22:47:36 05/02/2006 // Design Name: mux // Module Name: mux_tb.v // Project Name: com_link // Target Device: // Tool versions: // Description: // // Verilog Test Fixture created by ISE for module: mux // // Dependencies: // // Revision: // Revision 0.01 - File Created // Additional Comments: // //////////////////////////////////////////////////////////////////////////////// module mux_tb_v; // Inputs reg [7:0] data_in[0:31]; reg [4:0] sel; reg en; reg reset; integer k; // Outputs wire [7:0] data_out; // Instantiate the Unit Under Test (UUT) mux uut ( .data_out(data_out), .data_in[0:31](data_in[0:31]), .sel(sel), .en(en), .reset(reset) ); initial begin // Initialize Inputs for(k=0;k<32;k=k+1) begin //data_in[k] = 8'bz; end sel = 5'b0; en = 0; reset = 0; // Wait 100 ns for global reset to finish #100; // Add stimulus here end endmodule ============================================================================= please let me know whether the MUX's module is correct and if correct how to write the testbench for it. specifically i want to know the way i get the input to the MUX using a two dimentional array is correct. thank you CMOSArticle: 101529
Amontec, Larry schrieb: > > > > there are lots of small things... > > > > Antti > > > > It is very easy for vendors to be SVF compilant. Yes, it is. And no it isnt. And they are'nt. It would be easy for vendors to be more SVF compliant, but not to support ___ALL___ their products with plain vanilla SVF > SVF is well documented, and easy to understand. Yes it is. Still it's not a formal standard and less standard as STAPL (what is 'standard') > A JTAG stream based on SVF is very stable. Sure it is. > The only small things where troubles are coming from vendor is : > - in the FREQUENCY definition in the SVF files, > - in the need to repeat the last scan (SDR SIR) command if it failed. > Exactly - there are small problems, thats what I have said as well. > Our SVF player will have options to auto-detect the frequency, and to > allow the repeat of a scan if it failed. > And that SVF player will be able to use SVF generated by Vendor tools, and program amongst others: 1) Xilinx XC95, XC18, XCF 2) Lattice machXO, XP, all PLDs, ispClock, .. 3) Altera MAX2 4) Actel PA3 ?! If you do a very very good job (involving some AI built into the player) then I belive your player will program some chips from the list, but not all as SVF is not provided at all by all vendors, and SVF for the parts listed has special vendors things for the small things... > My long experience with JTAG topic let me say you, it is not so hard to > provide/write a generic SVF Player. > Dear Laurent, AGREE. 100 % percent. It' very easy to provide/write generic SVF player. It really is. So I wonder why the Amontec SVF player is announced for so long time with no date of release known? If it is so easy why isnt it available for Amontec customers? As of support for Coolrunner programming inside the Amontec Chameleon last I checked the configuration software from Amontec wasnt able to use XSVF files generated from last release of Xilinx tools, so Amontec 'invented' Amontex SVF, (file extension *.ASVF) that is actually just Xilinx XSVF generated with some out date and obsoleted XSVF tool? We have modified the XSVFplayer from Xilinx (updated version!) to support PINAPI(tm) drivers, and we have a driver to access the Coolrunner config jtag on Chameleon so we can configure Amontec Chameleon with 'standard XSVF' from Xilinx tools, whereis Amontex onw software can not do that (at least did not when I last checked) > From my experience Xilinx, Altera Lattice generate good SVF files. All > vendor have just advantage to respect SVF specification. > Yes they have (would have) advantage using plaind standard generic SVF but as the big boys really dont like the community sandbox so is the support of generic SVF also not nearly as good as it could be. Altera uses JAM/STAPL as primary, sure - they invented it, so no wonder they are not much interested in SVF or anything they did not invent. Actel uses STAPL as it capable to handle the flash programming without 'vendor extensions' - but unfortunatly they are doing that also not confirm, so the Actel STAPL is dedicated for Actel only Lattice has SVP+Plus and will keep using it, it's not standard, and no one else will be using it. For end users they have VME that provides all the necessary functions for flash devices, so chances to see full generic SVF from lattice (for all products) are nil as well. Xilinx defenetly doesnt want to deal with standards introduced by Altera (JAM/STAPL) so they are using their own derivate of SVF to support their flash devices. Again as SVF alone is not sufficent for the flash and Xilinx already has XSVF that no-other vendor will use then seeing full generic SVF for all Xilinx devices also not possible > Laurent > www.amontec.com Antti Lukats Xilant TechnologiesArticle: 101530
Hey Markus, thanx for the info...I did print this *.xdlrc before, but dint quiet understand the pips connection, would it be possible for u to explain me a little bit, i have understood the OMUX, IMUX, etc, but not the FAN_BX2...IOIS_BX2 etc....can you help me... thanx in advanceArticle: 101531
I have had experience managing workgroups of engineers working with MS VisualStudio. The project was started with SourceSafe but we switched to CVS. We gained availability - people from off site could access the CVS source trees more easily. But what we lost was convenience and easy of use of being able to check in changes from within VisualStudio. And, I couldn't determine if it was unfamiliarity with a new tool, but when we switched to CVS, conflict resolution became an issue. I have bid on projects that I have had in mind to have 4 to 8 engineers working on designs. What I have been on the look out for is workgroup software that integrates with the development environment so that engineers can stay focused on what they are working on and not distracted by resolving conflicts. I realize a lot of this has to do with who is working with what files. To summarize, I'm looking for something that I cost justify that it will increase employee efficiency. Is Altera or any body that Altera has a partnership with working on a workgroup development tools that integrate into QuartusII and SOPC Builder?Article: 101532
I can't say for the NIOS, but most of Altera's megawizard functions use an active-high clear, not an active-low. I would suggest inverting (or removing inversion from) the signal, and see if it works properly.Article: 101533
Hi Xilin, As a first time user of Xilinx ChipScope, I have many feelings about its usage. 1. First of all, it is an excellent tool that help FPGA designers debug designs in the easiest way. 2. It is easy for designers to change trigger data and all other things. 3. Its debugging waveform windows have many things to improve, in short, its waveform window interface is bad, but I think 2 persons and half a year are enough to raise its waveform interface up to world first class. The followings are 3 major suggestions: 1. Liberate waveform window from being a child window and let it become a frame window with its independent menus and commands that can be maximized to the full screen. It is not difficult to change, but it surely will give users more viewing area and more pleasure. Reason: when debugging a design, designers spend most of time viewing its waveforms. Current waveform window is too small to look around. Its size is limited by its mother window. 2. Currently for multiple-bit signals, a client has to do the following editing to get a bus signals(multiple-bit signals are most time viewed as a bus signal) standing beside a testing machine: a. Click the first line of the signal; b. Browse down to the last line of the signal (if it is 64-bit, a lot scroll down operations) c. Hold down the 'shift' key, then click the last line of the signal to select all signal bits; d. Right click to pop up an operation window; e. Select Generate a new bus; f. Left click 'new bus' item in the expanded menu. then g. repeat a. to d., then click 'cut' to cut all individual signals. If there are thousands of lines, it is not an easy job. Suggestion: Put a new window in ChipInsert software. After user selects all trigger signals, let user decide their show options(show the multiple-bit signal as a bus, and don't have to combine them and then cut them later, data values should be shown in highest to lowest mode or reversed mode) After loading the project into ChipScope, user never has to change those signal view property any more. Showing properties: a. Ability to shift a hex data right or left some bits to facilitate different viewing capabilities; b. Ability to show in binary, decimal, hex formats 3. Cursor has big problems: Two cursors are good, but each time when user clicks on the screen, no cursor movement. It is bad for a user to click 4-5 times to select which cursor to put. Suggestions: 1. Provide two icon in command bar. User can click any one of two icons, then when user click left button, the selected cursor will be put there, no matter how many time user clicks. This way, it will relieve users 4-5 clicks to put a cursor at the designated area. It is as easy as ModelSim, but give user more freedom to select which cursor has to be selected. The best way for an interface software designer to design a good interface is he must use it. When using it, he will find all those issues that are not friendly. Thank you. WengArticle: 101534
"Never" is a very strong word, and is almost never correct... Asynchronous reset inputs are perfectly safe to use, and often necessary when circuit response must be guaranteed, even in the absence of a clock. However, they must be used carefully, controlling the release of reset (actually a synchronous event) such that it meets setup and hold relative to the clock. What I recommend to resolve the release of reset problem is to synchronously release (deassert) the reset signal tied to the async reset inputs on the state registers. Note that the reset signal still asserts asynchronously, it only deasserts synchronously. rst: process (rstin, clk) is begin if rstin = '1' then rstmeta <= '1'; rstout <= '1'; elsif rising-edge(clk) then rstmeta <= '0'; -- potentially metastable rstout <= rstmeta; -- meta-rejected end if; end process; fsm: process (rstout, clk) is begin if rstout = '1' then state <= reset_state; elsif rising_edge(clk) then case state is ... end if; end process; AndyArticle: 101535
Hello Duane Got it! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you! Thank you!Article: 101536
"Fizzy" <fpgalearner@gmail.com> wrote in message news:1146554926.472729.204710@e56g2000cwe.googlegroups.com... > Hi, > > I need some direction and advice on integrating PLB slave. I have a > design which i want to integrate with processor using PLB. Any good > examples, tutorial or papers please. I am looking somthing like > designed in system generator > > Thanks In EDK click on Hardware and then on Create or Import Peripheral. It will open a wizard, which will create a framework design for you. /MikhailArticle: 101537
Jeff Brower wrote: > Eli- > > > So, if I cant use // or /* */, what can I use for commenting? > > By "line comments" I thought you meant C++ style comments. I've not > had trouble with /* ... */ in 7.1, only with //. My apologies for > answer that was not helpful. > > -Jeff I am the collegue Eli spoke of. I did not have problems with 7.1, only 8.1. I have also noticed that pushing the enter button does not go to the next line until I start typing after pressing enter. Also, after a // comment, if I press enter, the next line actually turns green. I had to delete and press enter a few times to get it to not show up green like a comment, but the synthesiser still recognizes it as one, as seen in Eli's example. -JonArticle: 101538
Derek Simmons wrote:
> I have bid on projects that I have had in mind to have 4 to 8 engineers
> working on designs. What I have been on the look out for is workgroup
> software that integrates with the development environment so that
> engineers can stay focused on what they are working on and not
> distracted by resolving conflicts. I realize a lot of this has to do
> with who is working with what files. To summarize, I'm looking for
> something that I cost justify that it will increase employee
> efficiency.
There are many windows text editors compatible out of the box
with the best of the open source version control systems.
However, visualstudio is not one of them.
http://groups.google.com/groups/search?q=editor+subversion+cvs+rcs+windows
-- Mike Treseler
Article: 101539Hi Weng, I'm not so concerned about the user interface. Although that Java stuff is bloody slow! What ChipScope really needs is a clock enable connection to go with the clock. That way it can be used and meet timing whatever your clock rate. (Or at least do much better than it does currently.) Cheers, Syms.Article: 101540
We are using VHDL on a new design with a Lattice 4256V and are running into problems with our shift registers. We're using ispLEVER 5.1 trial along with Synplicity synthesis. Here's our generic 11-bit shift register with async. parallel load: -- -- 11 bit shifter for data serialization -- library IEEE; use IEEE.STD_LOGIC_1164.all; use IEEE.STD_LOGIC_arith.all; use IEEE.STD_LOGIC_unsigned.all; entity shifter11 is port( clk:in std_logic; rst:in std_logic; data_in:in std_logic_vector(10 downto 0); shift_load_select:in std_logic; shift_in:in std_logic; data_out:out std_logic); end shifter11; architecture bhv of shifter11 is signal data_latched: std_logic_vector(10 downto 0); begin process(clk,rst,data_in,shift_load_select) begin if(rst='0') then data_latched <= "11111111111"; elsif(shift_load_select = '1') then data_latched <= data_in; elsif(clk'event and clk='1') then data_latched <= shift_in & data_latched(10 downto 1); end if; end process; data_out <= data_latched(0); end bhv; We have isolated the CPLD completely with nothing but a clock pin + reset as external input. With hard-coded input to the shift register and another test entity that does nothing but sniff the ouput and verify its correctness, we are occasionally running into problems. After many thousands of shifts + outputs over 20-60 seconds, there will be one or more bits flipped in the shift register output. 99.999% of the time the output is correct, we just can't figure out why this thing is failing. The issue seems to only occur when we place multiple shift registers in our design working in parallel, a single shift register alone will work error-free. To me this seems to indicate a tool issue when utilizing resources close to the limits of the chip. Another possibility is a hardware problem, however we have double and triple checked all ground / VCC pins and reduced the external inputs to the bare minimum. I started going through the generated postfit equations, however I started to get a headache after about the 100th flip flop. Any suggestions on how to fix this?Article: 101541
Dave wrote: > Hi group, > > Are there any problems with chaining multiple instances of the clock > doubler from this link together? > > http://www.xilinx.com/xlnx/xweb/xil_tx_display.jsp?sGlobalNavPick=&sSecondaryNavPick=&category=&iLanguageID=1&multPartNum=1&sTechX_ID=pa_six_easy > (http://tinyurl.com/aqk9f) (see section 6) > > Clock rate variations preclude the use of DCMs (even in low frequency > mode using CLKFX only). > > Many thanks for your time. What are you trying to do ? Chain of a simple clock doubler is not practical, but there are other solutions. eg If you need 8 clocks to spin a state engine, for each incomming edge, than that can be done. Create a Gated Ring Osc, counter and XOR CE, and clock the counter until chosen /N bit equals Fin. This gives a burst of edges, syncronised with the input signal, but they are not evenly spaced, or phase-located; You get (eg) 8 clocks for each input edge. -jgArticle: 101542
A shift register with asynchronous set and asynchronous load is not entirely "generic". I would look carefully at the load and reset logic generated. A glitch on a gated asynch input can cause severe problems. How is the asynchronous load implemented in the macrocell? Do you really need both load and reset terms to be asynchronous? shawnn@gmail.com wrote: > We are using VHDL on a new design with a Lattice 4256V and are running > into problems with our shift registers. We're using ispLEVER 5.1 trial > along with Synplicity synthesis. Here's our generic 11-bit shift > register with async. parallel load: > > -- > -- 11 bit shifter for data serialization > -- > library IEEE; > use IEEE.STD_LOGIC_1164.all; > use IEEE.STD_LOGIC_arith.all; > use IEEE.STD_LOGIC_unsigned.all; > > entity shifter11 is > port( > clk:in std_logic; > rst:in std_logic; > data_in:in std_logic_vector(10 downto 0); > shift_load_select:in std_logic; > shift_in:in std_logic; > data_out:out std_logic); > end shifter11; > > architecture bhv of shifter11 is > signal data_latched: std_logic_vector(10 downto 0); > begin > process(clk,rst,data_in,shift_load_select) > begin > if(rst='0') then > data_latched <= "11111111111"; > elsif(shift_load_select = '1') then > data_latched <= data_in; > elsif(clk'event and clk='1') then > data_latched <= shift_in & data_latched(10 downto 1); > end if; > end process; > data_out <= data_latched(0); > end bhv; > > > We have isolated the CPLD completely with nothing but a clock pin + > reset as external input. With hard-coded input to the shift register > and another test entity that does nothing but sniff the ouput and > verify its correctness, we are occasionally running into problems. > After many thousands of shifts + outputs over 20-60 seconds, there will > be one or more bits flipped in the shift register output. 99.999% of > the time the output is correct, we just can't figure out why this thing > is failing. > > The issue seems to only occur when we place multiple shift registers in > our design working in parallel, a single shift register alone will work > error-free. To me this seems to indicate a tool issue when utilizing > resources close to the limits of the chip. > > Another possibility is a hardware problem, however we have double and > triple checked all ground / VCC pins and reduced the external inputs to > the bare minimum. > > I started going through the generated postfit equations, however I > started to get a headache after about the 100th flip flop. > > Any suggestions on how to fix this?Article: 101543
shawnn@gmail.com wrote: > We are using VHDL on a new design with a Lattice 4256V and are running > into problems with our shift registers. We're using ispLEVER 5.1 trial > along with Synplicity synthesis. Here's our generic 11-bit shift > register with async. parallel load: > > -- > -- 11 bit shifter for data serialization > -- > library IEEE; > use IEEE.STD_LOGIC_1164.all; > use IEEE.STD_LOGIC_arith.all; > use IEEE.STD_LOGIC_unsigned.all; > > entity shifter11 is > port( > clk:in std_logic; > rst:in std_logic; > data_in:in std_logic_vector(10 downto 0); > shift_load_select:in std_logic; > shift_in:in std_logic; > data_out:out std_logic); > end shifter11; > > architecture bhv of shifter11 is > signal data_latched: std_logic_vector(10 downto 0); > begin > process(clk,rst,data_in,shift_load_select) > begin > if(rst='0') then > data_latched <= "11111111111"; > elsif(shift_load_select = '1') then > data_latched <= data_in; > elsif(clk'event and clk='1') then > data_latched <= shift_in & data_latched(10 downto 1); > end if; > end process; > data_out <= data_latched(0); > end bhv; > > > We have isolated the CPLD completely with nothing but a clock pin + > reset as external input. With hard-coded input to the shift register > and another test entity that does nothing but sniff the ouput and > verify its correctness, we are occasionally running into problems. > After many thousands of shifts + outputs over 20-60 seconds, there will > be one or more bits flipped in the shift register output. 99.999% of > the time the output is correct, we just can't figure out why this thing > is failing. "async. parallel load" can be dangerous - what releases the Load signal, relative to the Clock ? If your load has no release precautions, then yes, you can expect nasty aperture effects if/when the release hits a shift clock edge. > > The issue seems to only occur when we place multiple shift registers in > our design working in parallel, a single shift register alone will work > error-free. To me this seems to indicate a tool issue when utilizing > resources close to the limits of the chip. If it mostly works, then it is not likely to be a tool-error. Fuse/map errors tend to be hard, in nature. If you added an Nth bock, and that (or other) blocks then fail (always), that is (likely) a tool chain issue. > Another possibility is a hardware problem, however we have double and > triple checked all ground / VCC pins and reduced the external inputs to > the bare minimum. > > I started going through the generated postfit equations, however I > started to get a headache after about the 100th flip flop. > > Any suggestions on how to fix this? -jgArticle: 101544
Any buddy know how the following can be done. I need to connect the model developed in sysgen to EDK desgin. The EDK design has PowerPC405 so EDK Pcore block in Sysgen is useless as it only supports FSL for microblaze... Any suggestion how it can be done... Only objective is to integrate some model developed to PLB bus in EDK as user coreArticle: 101545
Hi Everyone, Can someone open a Tech Support case on this issue? It has nothing to do with the fact XST does not support the comment style. This has always worked. The problem is that you are using reserved words in verilog. There is a fine distinguising part here as well. XST needs to read through the comments to get the synthesis attribute keywords. There sounds to be a bug where we are only looking at keywords and not looking for the synthesis attribute statement. This is a bug and the reason why it worked in 7.1i and not in 8.1i is because this capability was moved from the engine to the parser and the parser somehow missed out on this check. Thus it looks like ISE 8.1i broke something. There should be a way to work around this too. Try the following change to your comment: From: /*inputs outputs registers wires*/ To: /*This section declares the inputs outputs registers wires for the module*/ Either way it is a bug and so go ahead and open a Xilinx Tech Support case on it. Thanks Duth kash.jt@gmail.com wrote: > Jeff Brower wrote: > > Eli- > > > > > So, if I cant use // or /* */, what can I use for commenting? > > > > By "line comments" I thought you meant C++ style comments. I've not > > had trouble with /* ... */ in 7.1, only with //. My apologies for > > answer that was not helpful. > > > > -Jeff > > I am the collegue Eli spoke of. I did not have problems with 7.1, only > 8.1. I have also noticed that pushing the enter button does not go to > the next line until I start typing after pressing enter. Also, after a > // comment, if I press enter, the next line actually turns green. I had > to delete and press enter a few times to get it to not show up green > like a comment, but the synthesiser still recognizes it as one, as seen > in Eli's example. > > -JonArticle: 101546
How about a firefly mimic? If you are lucky enough to live somewhere that has fireflies, you could make a green LED blink like a firefly's bum, and thus attract a swarm of them eventually. I think there is a snag in that some fly in a sort of J shaped path during their lit period. Behaviour varies between species. Also, it seems the males fly and flash while looking for mates, and the stationary female flashes in response. I guess males might be attracted even if the did not flash first. They may think they've found a lady firefly with an absolutely enormous bum, but ultimately they will be disappointed. If you'd like to get into firefly sex (not implying you are amazingly small in the dingly-dangly department of course), then here might be a good place to start: http://en.wikipedia.org/wiki/Firefly Another insect you might mimic is the cricket. Apparently they chirp at a rate related to temperature. Thus you could have a temp sensor input with an audio output. And I find their chirping very pleasing to the ears. http://en.wikipedia.org/wiki/Cricket_%28insect%29Article: 101547
Could there be more than one issue here ? Someone said it also fails in v7.1i, and to avoid //, - your example is slightly different, showing a parser/keyword-in-comnent problem ? -jg Duth wrote: > Hi Everyone, > > Can someone open a Tech Support case on this issue? It has nothing to > do with the fact XST does not support the comment style. This has > always worked. The problem is that you are using reserved words in > verilog. There is a fine distinguising part here as well. XST needs to > read through the comments to get the synthesis attribute keywords. > There sounds to be a bug where we are only looking at keywords and not > looking for the synthesis attribute statement. > > This is a bug and the reason why it worked in 7.1i and not in 8.1i is > because this capability was moved from the engine to the parser and the > parser somehow missed out on this check. Thus it looks like ISE 8.1i > broke something. > > There should be a way to work around this too. Try the following change > to your comment: > > From: > > /*inputs outputs registers wires*/ > > To: > > /*This section declares the inputs outputs registers wires for the > module*/ > > Either way it is a bug and so go ahead and open a Xilinx Tech Support > case on it. > > Thanks > Duth > > > kash.jt@gmail.com wrote: > >>Jeff Brower wrote: >> >>>Eli- >>> >>> >>>>So, if I cant use // or /* */, what can I use for commenting? >>> >>>By "line comments" I thought you meant C++ style comments. I've not >>>had trouble with /* ... */ in 7.1, only with //. My apologies for >>>answer that was not helpful. >>> >>>-Jeff >> >>I am the collegue Eli spoke of. I did not have problems with 7.1, only >>8.1. I have also noticed that pushing the enter button does not go to >>the next line until I start typing after pressing enter. Also, after a >>// comment, if I press enter, the next line actually turns green. I had >>to delete and press enter a few times to get it to not show up green >>like a comment, but the synthesiser still recognizes it as one, as seen >>in Eli's example. >> >>-Jon > >Article: 101548
on the Lattice website forums http://www.latticesemi.com/forums/forum/messageview.cfm?catid=134&threadid=2062&enterthread=y Lattice's response was as follows: ------------------------------------------------------ The fact that the error happens occasionally, and doesn't happen at all with fewer shift registers, suggests that it's either a timing issue or a board level issue. If the error occured all of the time, or when it went bad it stayed bad, I would agree that it could be a logic problem. By the way, does the design occasionally not drive a bit high (a hole in the shift sequence) or does the shift sequence get off by a clock? Is it happening on all shift registers, or just one? Make sure that you have set proper timing contraints for your design and that you check the log files for violations. Assuming the timing looks good, I'd check your board level design. Make sure you aren't overworking the outputs, take a look at page 20 of the datasheet. Keep in mind that if you are driving many loads all at once you can create ground bounce significant enough to affect the part. You might try different input patterns to see if this changes things (use a pattern that generates less toggling of the outputs). Also check that you have sufficient numbers of high frequency (.1uf or .01uf) and mid frequency (10uf to 47uf) capacitors. Check that your power supply isn't drooping. Check that the power supply doesn't get more noisy as the load increases. ------------------------------------------------------ Hope this helps! Bart Borosky Online Marketing Manager Lattice SemiconductorArticle: 101549
The APU might work well for that. It's closer to the FSL than the PLB and OPB are, and it's faster. But I'm assuming your PPC405 is in a V4 ... -Greg
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