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
I have the full license for Quartus and can't compile a simple project targeting the GX device until I enable the talkback feature. What gives? Suppose the PC is not on the internet, you can't use the GX parts? Is this stupid or what? I would expect this sort of thing from the free tools. Get rid of the spyware.Article: 100301
On Thu, 06 Apr 2006 11:01:36 GMT, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote: >On a sunny day (Wed, 05 Apr 2006 17:47:09 -0700) it happened John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in ><a0p832tsdsap1ivpo4ok0fqearc8s6iad1@4ax.com>: > >>On 5 Apr 2006 14:00:24 -0700, panteltje@yahoo.com wrote: >> >>> >>>John Larkin schreef: >>> >>> >>>> And if I had the Verilog, the first thing I'd do is grab a piece of >>>> paper and sketch it out to understand what it does. >>>> >>>> Some people think verbally, some visually. >>>> >>>> John >>>OK, so say I wanted a low pass, and wrote: >>> >>>/* 12.5 MHz clock chroma lowpass */ >>>`define F0 0 >>>`define F1 -2 >>>`define F2 2 >>>`define F3 8 >>>`define F4 -3 >>>`define F5 -21 >>>`define F6 5 >>>`define F7 80 >>>`define F8 127 >>>`define F9 80 >>>`define F10 5 >>>`define F11 -21 >>>`define F12 -3 >>>`define F13 8 >>>`define F14 2 >>>`define F15 -2 >>>`define F16 0 >>> >>> >>>module fir( clock, fir_in, fir_out); >>>wire clock; >>>input fir_in; >>>output fir_out; >>> >>>wire [7:0] fir_in; >>>reg [7:0] fir_out; >>>reg [31:0] temp; >>> >>>reg [7:0] sm0; >>>reg [7:0] sm1; >>>reg [7:0] sm2; >>>reg [7:0] sm3; >>>reg [7:0] sm4; >>>reg [7:0] sm5; >>>reg [7:0] sm6; >>>reg [7:0] sm7; >>>reg [7:0] sm8; >>>reg [7:0] sm9; >>>reg [7:0] sm10; >>>reg [7:0] sm11; >>>reg [7:0] sm12; >>>reg [7:0] sm13; >>>reg [7:0] sm14; >>>reg [7:0] sm15; >>>reg [7:0] sm16; >>> >>> >>>always @(posedge clock) >>>begin >>> sm16 = sm15; >>> sm15 = sm14; >>> sm14 = sm13; >>> sm13 = sm12; >>> sm12 = sm11; >>> sm11 = sm10; >>> sm10 = sm9; >>> sm9 = sm8; >>> sm8 = sm7; >>> sm7 = sm6; >>> sm6 = sm5; >>> sm5 = sm4; >>> sm4 = sm3; >>> sm3 = sm2; >>> sm2 = sm1; >>> sm1 = sm0; >>> sm0 = fir_in; >>> >>>temp = >>> (`F0 * sm0) + (`F1 * sm1) + (`F2 * sm2) + (`F3 * sm3) + >>> (`F4 * sm4) + (`F5 * sm5) + (`F6 * sm6) + (`F7 * sm7) + >>> (`F8 * sm8) + (`F9 * sm9) + (`F10 * sm10) + (`F11 * sm11) + >>> (`F12 * sm12) + (`F13 * sm13) + (`F14 * sm14) + (`F15 * sm15) + (`F16 >>>* sm16); >>> >>>fir_out = temp / 512; >>>end >>> >>>---------- >>>How would you draw that? >>> >> >>The same way people drew FIR filters before HDLs were invented. It's >>very simple and very intuitive... looks just like an analog >>transversal filter. >> >>John >Sure, possible. >But this IS a lot faster, and more readable in my view. >Actually I tried it that way (you describe), and even to get a 64 order >you will need a BIG piece of paper..... make it 32 wide... >But nobody is stopping you. Actually, some things, like FIRs, may as well be in a box on the schematic, and be HDL or whatever inside, as long as the function is routine, as an FIR is. Some stuff, like big address decoders for example, really work better as text. But the big picture, and even much of the control logic, make more sense to me as schematics... I can *see* what's happening in a flash, as opposed to reading and decoding 6000 lines of uncommented HDL. The schematics themselves should be heavily commented, of course. I do like the idea of designing as close as possible to the chip's actual cell architecture, which I find easier to do visually. Again, it depends on how your brain works. Schematics and HDLs are just interfaces. JohnArticle: 100302
PeterC wrote:
> Thank you Brian - pointers to answer records and the past thread
> greatly appreciated.
Sure; I can't find my folder of DCM simulation notes right now, but
searching the Xilinx Answer Records for "DCM" or "DCM simulation"
will turn up a boatload of the DCM simulation quirks; I've listed some
more of them below.
You may also want to try running a post-PAR timing simulation to see
what the DCM delay looks like with the back-annotated delays.
11067 SimPrim - ModelSim Simulations: Input and Output clocks
of the DCM and CLKDLL models do not appear to be de-skewed
13213 UniSim, SimPrim, Simulation - How do I simulate the DCM
without connecting the CLK Feedback (CLKFB) port? (VHDL)
11344 UniSim - Variables passed to GENERICs in functional simulation
are not working properly (VHDL)
18390 7.1i Timing Analyzer/TRACE - Changing the DESKEW_ADJUST
parameter does not affect the DCM value (Tdcmino)
20845 6.3i UniSim, Simulation- There is a Delta-cycle difference
between clk0 and clk2x in the DCM model
22064 7.1i UniSim, Simulation - There is a Delta-cycle difference
between CLK0 and CLKDV in the DCM model
6362 UniSim, SimPrim, Simulation - When I simulate a DCM or CLKDLL,
the LOCKED signal does not activate unless simulation is run in
ps time resolution
18115 8.1i/7.1i Simulation - DCM outputs are "0" and the DCM does not
lock UniSim and SimPrim VHDL models) (DCM reset requirement)
19005 Virtex-II/Virtex-II Pro, Clocking Wizard - The LOCKED signal
doed noy go high for cascaded DCM when CLKDV is used
have fun,
Brian
Article: 100303raphael wrote: > hello folks, i'm working with a avnet board that has a xc2v1500 and > i've been trying to use the ddr memory it has. i can't get it to work, > when i start the placement, edk complains that the placement > constraints, that is the ddr pin assignment, are causing an IOB > conflict. i've tried to use floorplanner to solve the conflicts but it > didn't help. i'll send the error output and if someone knows of > something i can do, or have had the same problem and can help me out i > would be glad. > > Phase 12.24 > ERROR:Place:17 - The placement constraints of the IOBs > fpga_0_Generic_DDR_DDR_DM_pin<0> and > fpga_0_Generic_DDR_DDR_DQS_pin<0> makes this design unroutable due > to a physical routing limitation. This device has > a shared routing resource connecting the ICLK and OTCLK pins on > pairs of IOBs. This restriction means that these > pairs of pins must be driven by the same signal or one of the > signals will be unroutable. Before continuing please > remove the placement constraints or move one of these IOBs to a new > location. This is a hardware bug on the Avnet boards. As the error message indicates, the Virtex2 chips used shared clocking resources on pairs of pins, restricting how they can be used particularly when using DDR registers. Avnet violated those restrictions. The easiest way to understand what is happening is to open up the chip in FPGA editor, and take a look at how the clocks are to the pair of IO blocks where the problem is happening. Assuming that during a transfer/burst you will not be changing the DM signals, you can work around this problem by using the DQS clock on the DM signals. In this case, the DM signals would need to be valid half a clock early at the start of a transfer/burst, and held valid for an extra half a clock at the end. As for the CKE signal, that one doesn't really change after init, so you can just add an extra output FF clocked with the DQS clock.Article: 100304
Jeff Brower wrote: > MK- > > On the other hand, Slurp's great-looking example was mostly data flow > -- block diagrams are extremely good for depicting signal processing > and other data-driven algorithms. You could take your optimized > Verilog and go back to schematic form again and still be able to see > what's going on. > > But not so for protocols, state machines, bus switching, and other > "control flow". All control flow paths must be shown in a schematic, > making it difficult to clearly recognize one path or another and either > focus on it or ignore it -- something easy to do with an "if else" in > code or a "decision block" in a flow diagram. > > -Jeff > For what it is worth, back when I was doing schematics I was using wrappers around flip-flops and gates that looked like state diagram elements. The state bubble contained a flip-flop , a decision block was contained pair of And gates and had one extra "pin" for the decision, and T junctions on the diagram had OR gates under them. It made for a very quick (in terms of schematic entry time) entry and easy to understand schematics. the point is there are ways to make schematics much more usable in design entry, and they are more or less self documenting as long as they are done hierarchically, using sensible symbols and sensible partitioning. By the same token, HDL can be made to be horrendous as well. The biggest drawback to schematic entry in my mind is that the file format is proprietary, which makes it basically non-portable between tools (or in some cases between versions of the same tool), and you need a viewer to look at the files, where HDL entered design only needs a text editor to view the design.Article: 100305
Zara wrote: > On Wed, 5 Apr 2006 05:25:59 -0700, ahakan <> wrote: > > >Thanks for your response, but I am using Parallel Cable IV, so I guess the problem is not due to the parallel cable (I tried the Platform Cable USB as well). > > > I have the same problem from time to time with PCIV (not tried with > other cables) and XC3S400. > > Sometimes it is just a momentary problem, you muts just try again and > it programs OK. Sometimes it is plain stupidity of (I suppose) the > FPGA, switch power off and on again, it usually works. > > Best regards, > > Zara Hi, I have had this problem with certain bit files on Spartan 2, 2e and 3. If you are just loading the FPGA then power cycling will probably be adequate - if you are using FLash to program the FPGA at power up you may need to erase the flash first, then power cycle. kevinArticle: 100306
Hi, I'm evaluating one option to transmit images over Gigabit Ethernet. The most efficient is the GSRD desing with the Treck TCP/IP stack using jumbo frames, but the Treck stack is not free and I'm thinking in others TCP/IP stacks like LwIP. If LwIP or uIP can support jumbo frames I would like to use them. Another question is the device utilization grade of the temac design (79% of slices!!). There is no space enough for another sistems in the ML403 board, I will open one discussion about this. ThanksArticle: 100307
Hi This example (xapp807) don't use the LwIP stack. It use the uIP stack, free also.Article: 100308
I don't think I can help with your problem, but I'm happy to complain about the option along with you ;-). I've seen the same problem with registers left in there for output IOBs being removed. It seems that the option fixes some of the removal but not all of it because my output files definitely have more registers when the removal is disabled. You turn it on thinking that it will optimize your code, and then you are left without sufficient registers to put one in each IOB. Hence, your OFFSET timing all fails and you wonder what the heck happened. I think this optimization should happen after the mapping. I was grateful that Xilinx is finally realizing the fact that most optimizations should happen in the mapper. Perhaps some other XST option overrides some of the removal or makes the registers unusable in the IOB, such as the optimize for speed parameter. Here is my option set that is removing more than I think it should or at least not allowing IOB USE. set -tmpdir ./xst/projnav.tmp set -xsthdpdir ./xst run -ifn ql5064_interface.prj -ifmt mixed -ofn ql5064_interface -ofmt NGC -p xc4vlx100-10-ff1513 -top ql5064_interface -opt_mode Speed -opt_level 2 -iuc NO -lso ql5064_interface.lso -keep_hierarchy SOFT -rtlview Yes -glob_opt AllClockNets -read_cores YES -write_timing_constraints NO -cross_clock_analysis NO -hierarchy_separator / -bus_delimiter <> -case maintain -slice_utilization_ratio 100 -dsp_utilization_ratio 100 -verilog2001 YES -fsm_extract YES -fsm_encoding Auto -safe_implementation Yes -fsm_style lut -ram_extract Yes -ram_style Auto -rom_extract Yes -mux_style Auto -decoder_extract YES -priority_extract YES -shreg_extract YES -shift_extract YES -xor_collapse YES -rom_style Auto -mux_extract YES -resource_sharing YES -use_dsp48 auto -iobuf NO -max_fanout 10000 -bufg 32 -bufr 48 -register_duplication YES -register_balancing No -slice_packing YES -optimize_primitives YES -use_clock_enable Auto -use_sync_set Auto -use_sync_reset Auto -iob auto -equivalent_register_removal NO -slice_utilization_ratio_maxmargin 5Article: 100309
hi, I just carried out BIST test on the XUPV2P board and I have been running the memory test several times and still getting the same failure. The DDR used for test is a 512 Mb. Has anyone experience this problem or could the test been designed to test a 256 Mb instead of 512 Mb ? Cheers Paul DDR SDRAM Test: Rank 0 ---------------------- Running Data Walking 1's Test... SUCCESS! Running Data Walking 0's Test... SUCCESS! Running Address Walking 1's Test... SUCCESS! Running Address Walking 0's Test... SUCCESS! Running Device Pattern 1 Test... FAILED! Address: 0x03FFEB70, Expected: 0x00000000007FFD6F, Actual: 0x00000000FF7FFD6F DDR SDRAM Test: Rank 1 ---------------------- Running Data Walking 1's Test... SUCCESS! Running Data Walking 0's Test... SUCCESS! Running Address Walking 1's Test... SUCCESS! Running Address Walking 0's Test... SUCCESS! Running Device Pattern 1 Test... FAILED! Address: 0x17FFEB70, Expected: 0x0000000000FFFD6F, Actual: 0x00000000FFFFFD6FArticle: 100310
Hi I'm evaluating one Gigabit Ethernet design who use the hard Temac embedded in the Virtex-4 FX (ML403 evaluation board) for fast image transmision. The GSRD reference design (xapp546) is my best option, but have a 79% of occupied slices and I need more space for more components and the Treck TCP/IP used is a evaluation versión. It exist the option of the TEMAC UltraController-II but it seem that the PowerPC processor of the Virtex-4 can't be used for others issues and I don't know if the uIP TCP/IP stack used in this design supports Jumbo frames like Treck stack. This jumbo frames are needed for maximum performance at gigabit ethernet. Somebody have a easy solution to this problem? Another design? Thank you very much.Article: 100311
Hi Mitch Mich wrote: > this is what I have done > first I added this in the vhdl > test_I : in std_logic_vector (7 downto 0); > test_O : out std_logic_vector (7 downto 0); > test_T : out std_logic_vector (7 downto 0); > and this > s_test <= test_I; > test_O <= s_test; > test_T <= "00001111"; VHDL seems OK, except endianicity (normal is - 0 to 7 !) > then I have added this in the MPD file > PORT test = "", DIR = INOUT, ENABLE=SINGLE, THREE_STATE=TRUE, VEC = > [7:0] ERROR: ENABLE=MULTI !!!!!!! and maybe endianicity [0:7] As an example take a look at OPB_DDR MPD: PORT DDR_DQS = "", DIR = IO, VEC = [0:((C_DDR_DWIDTH/8)-1)], THREE_STATE = TRUE, ENABLE = MULTI, PERMIT = BASE_USER, DESC = 'DDR Data Strobe', IO_IF = ddr_0, IO_IS = data_strobe DELETE THIS PART!! > PORT test_I = "", DIR = IN, VEC = [7:0] > PORT test_O = "", DIR = OUT, VEC = [7:0] > PORT test_T = "", DIR = OUT, VEC = [7:0] > and this in the ucf file > Net IO_0_test_pin Loc = "N6"; > Net IO_0_test_pin IOSTANDARD = LVTTL; UCF Seems fine, but only for ONE test pin, for multiple pins look at the example: NET "gmii_txd<0>" LOC = "M4"; NET "gmii_txd<1>" LOC = "N4"; NET "gmii_txd<2>" LOC = "L1"; NET "gmii_txd<3>" LOC = "M1"; NET "gmii_txd<4>" LOC = "P2"; NET "gmii_txd<5>" LOC = "N5"; NET "gmii_txd<6>" LOC = "P4"; NET "gmii_txd<7>" LOC = "P5"; Cheers, GuruArticle: 100312
simon.stockton@baesystems.com schrieb: > Dear All, > > I am a little confused with regards to the clocking arrangement > associated with the Xilinx Rocket IO MGT. > > I want to use the MGT in Half Rate Mode with no 8B/10B encoding / > decoding with a byte wide interface (actually 10-bit wide due to not > using the 8B/10B). > > I have the following clocks (as per page 54 of the Rocket IO User Guide > [Vertex-II Pro]): > > REFCLK > tied to the pre-DCM input clock (clkin) > RXUSRCLK & TXUSRCLK > tied to the DCM output clock (div2) > RXUSRCLK2 & TXUSRCLK2 > tied to the DCM output clock (clk0) > > My question is which clock do I use to clock my data TO the MGT and > conversely FROM the MGT? > > The user guide says "Each edge of the slower clock must align with the > falling edge of the faster clock", as a result it suggests that > TXUSRCLK2 & RXUSRCLK2 are inverted so that clk0 can be used instead of > clk180. > > "Since clk0 is needed for feedback, it can be used instead of clk180 to > clock USRCLK or USRCLK2 of the transceiver with the use of the > transceiver's local inverter, saving a global buffer (BUFG)." > > My second question is, if the answer to question 1 is TXUSRCLK2 & > RXUSRCLK2 as suggested in the User Guide, is it permissible to invert > the RXUSRCLK & TXUSRCLK's instead of inverting the TXUSRCLK2 & > RXUSRCLK2 to assist with clock alignment in other areas in my design? > > Many Thanks, > > Simon > Hello Simon, 1st question: For your user interface you should use the usrclk2. This clock depends on the data width. 2nd question: the relationship between the REFCLK and the USRCLK is not so important because you can use the FIFO´s and the clock-correction-codes. There is generally a delta time between the REFCLK and the USRCLK over the DCM. HelmutArticle: 100313
I have used this test with Kinston RAM (512MB) that I bought from the digilent website. I remeber that I had to get some settings correct in the constraints file and the mhs file before RAM would work correctly. IF I remember correctly, the phase shift on the DCM for the DDR had to be changed. Here are my settings: #INST "dcm_1/dcm_1/DCM_INST" CLKOUT_PHASE_SHIFT = "FIXED"; #INST "dcm_1/dcm_1/DCM_INST" PHASE_SHIFT = "60"; BEGIN plb_ddr PARAMETER INSTANCE = DDR_512MB_64Mx64_rank2_row13_col10_cl2_5 PARAMETER HW_VER = 1.11.a PARAMETER C_PLB_CLK_PERIOD_PS = 10000 PARAMETER C_NUM_BANKS_MEM = 2 PARAMETER C_NUM_CLK_PAIRS = 4 PARAMETER C_INCLUDE_BURST_CACHELN_SUPPORT = 1 PARAMETER C_REG_DIMM = 0 PARAMETER C_DDR_TMRD = 20000 PARAMETER C_DDR_TWR = 20000 PARAMETER C_DDR_TRAS = 60000 PARAMETER C_DDR_TRC = 90000 PARAMETER C_DDR_TRFC = 100000 PARAMETER C_DDR_TRCD = 30000 PARAMETER C_DDR_TRRD = 20000 PARAMETER C_DDR_TRP = 30000 PARAMETER C_DDR_TREFC = 70300000 PARAMETER C_DDR_AWIDTH = 13 PARAMETER C_DDR_COL_AWIDTH = 10 PARAMETER C_DDR_BANK_AWIDTH = 2 PARAMETER C_DDR_DWIDTH = 64 PARAMETER C_DDR_CAS_LAT = 3 PARAMETER C_MEM0_BASEADDR = 0x00000000 PARAMETER C_MEM0_HIGHADDR = 0x0fffffff PARAMETER C_MEM1_BASEADDR = 0xe0000000 PARAMETER C_MEM1_HIGHADDR = 0xefffffff BUS_INTERFACE SPLB = plb PORT PLB_Clk = sys_clk_s PORT DDR_Addr = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_Addr PORT DDR_BankAddr = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_BankAddr PORT DDR_CASn = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_CASn PORT DDR_CKE = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_CKE PORT DDR_CSn = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_CSn PORT DDR_RASn = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_RASn PORT DDR_WEn = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_WEn PORT DDR_DM = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_DM PORT DDR_DQS = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_DQS PORT DDR_DQ = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_DQ PORT DDR_Clk = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_Clk & ddr_clk_feedback_out_s PORT DDR_Clkn = fpga_0_DDR_512MB_64Mx64_rank2_row13_col10_cl2_5_DDR_Clkn & 0b0 PORT Clk90_in = clk_90_s PORT Clk90_in_n = clk_90_n_s PORT PLB_Clk_n = sys_clk_n_s PORT DDR_Clk90_in = ddr_clk_90_s PORT DDR_Clk90_in_n = ddr_clk_90_n_s END Paul Lee wrote: > hi, > > I just carried out BIST test on the XUPV2P board and I have been > running the memory test several times and still getting the same > failure. > > The DDR used for test is a 512 Mb. > Has anyone experience this problem or could the test been designed to > test a 256 Mb instead of 512 Mb ? > > Cheers > > Paul > > > DDR SDRAM Test: Rank 0 > ---------------------- > Running Data Walking 1's Test... SUCCESS! > Running Data Walking 0's Test... SUCCESS! > Running Address Walking 1's Test... SUCCESS! > Running Address Walking 0's Test... SUCCESS! > Running Device Pattern 1 Test... FAILED! > Address: 0x03FFEB70, Expected: 0x00000000007FFD6F, Actual: > 0x00000000FF7FFD6F > > DDR SDRAM Test: Rank 1 > ---------------------- > Running Data Walking 1's Test... SUCCESS! > Running Data Walking 0's Test... SUCCESS! > Running Address Walking 1's Test... SUCCESS! > Running Address Walking 0's Test... SUCCESS! > Running Device Pattern 1 Test... FAILED! > Address: 0x17FFEB70, Expected: 0x0000000000FFFD6F, Actual: > 0x00000000FFFFFD6F >Article: 100314
> I agree the software is complicated. (Way too complicated in my opinion.) if "software" is referring to the firmware: this is really not too complicated. Have a look here: * www.usb-by-example.com * www.lvr.com > But all the solutions out there seem to be built around a little 8-bit > micro. You don't think it's silly to have a 10 million gate FPGA sitting > next to an 8051? disagreed. There are two types of data to be very clearly separated: * asynchronous data: this is all the USB device enumeration and control stuff. This is low bandwidth, most of it happens only during device attachment, and this is quite simple. An 8051 is still too complex to handle this, there are designs out there using a simple state machine. * isochronous data: this is all the traffic your application requires. In case you are streaming high bandwidth data and you need to do some processing on it, an FPGA might be a good solution. You will usually not want to pass 480Mbps of data through a CPU. Think of audio or video applications, USB protocol analyzers, ... Any comments welcome, best regards, Felix -- Dipl.-Ing. Felix Bertram http://www.bertram-family.com/felixArticle: 100315
On Thu, 06 Apr 2006 14:22:34 +0100, MikeShepherd564@btinternet.com wrote: >I've seen a similar problem today and I now suspect that it is caused >when there are output signals at the top level of the design which are >not assigned to pins. (This is an easy way to make them appear in the >simulation report). As I start assigning the diagnostic top-level >signals to unused pins, the problems go away. > >Am I missing something here? Am I making a fundamental mistake or is >there a Quartus option "Connect Unassigned Top-level Signals to Random >Device Pins Without Asking Me" This is not an option but the default. Top level pins are device pins and when they are unassigned Altera tools select the "best" location for them. After all they have to go to some where. Sometimes this is useful at the very start of the project where you really don't care where the pins get assigned. You should just assign them to some safe locations if you don't want this to happen.Article: 100316
rOn Thu, 06 Apr 2006 06:57:00 -0700, "Mike Treseler" <mike_treseler@comcast.net> wrote: >MikeShepherd564@btinternet.com wrote: > >> Am I missing something here? Am I making a fundamental mistake or is >> there a Quartus option "Connect Unassigned Top-level Signals to Random >> Device Pins Without Asking Me" or "Poke Unassigned Top-level Signals >> into some Lower-level Module" ? > >Quartus does reserve the right to drive "unused" >pins with random internal nodes. Do you have a reference for this ?Article: 100317
lecroy7200@chek.com wrote:
> I have the full license for Quartus and can't compile a simple project
> targeting the GX device until I enable the talkback feature. What
> gives? Suppose the PC is not on the internet, you can't use the GX
> parts?
Try it and see.
Section 9 of the License Agreement says
that it stores the xml files on disk
in that case. It doesn't say it stops working.
-- Mike Treseler
Article: 100318If I don't use BUS_INTERFACE it says my FSL is not connected to anything. Here is my MHS file. Does anyone have an idea how to make it work, or at least what's wrong with it? At this point, I'm just trying to get a single slave FSL working. To me that means an FSL which inputs data into microblaze from my ISE project (VHDL). PARAMETER VERSION = 2.1.0 PORT fpga_0_LEDs_8Bit_GPIO_d_out_pin = fpga_0_LEDs_8Bit_GPIO_d_out, VEC = [0:7], DIR = O PORT fpga_0_Push_Buttons_3Bit_GPIO_in_pin = fpga_0_Push_Buttons_3Bit_GPIO_in, VEC = [0:0], DIR = I PORT fpga_0_DIP_Switches_8Bit_GPIO_in_pin = fpga_0_DIP_Switches_8Bit_GPIO_in, VEC = [0:7], DIR = I PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = CLK PORT sys_rst_pin = sys_rst_s, DIR = I PORT ext_interrupt = ext_interrupt, DIR = I, SIGIS = Interrupt, SENSITIVITY = EDGE_RISING PORT FSL0_M_Clk = FSL0_M_Clk, DIR = I PORT FSL0_M_Data = FSL0_M_Data, DIR = I, VEC = [0:31] PORT FSL0_M_Write = FSL0_M_Write, DIR = I PORT FSL0_M_Full = FSL0_M_Full, DIR = O PORT FSL0_S_CLK = fsl0_s_clk, DIR = O PORT FSL0_S_DATA = fsl0_s_data, DIR = I, VEC = [0:31] PORT FSL0_S_EXISTS = fsl0_s_exists, DIR = I PORT FSL0_S_READ = fsl0_s_read, DIR =O BEGIN microblaze PARAMETER INSTANCE = microblaze_0 PARAMETER HW_VER = 4.00.a PARAMETER C_DEBUG_ENABLED = 0 PARAMETER C_NUMBER_OF_PC_BRK = 0 PARAMETER C_NUMBER_OF_RD_ADDR_BRK = 0 PARAMETER C_NUMBER_OF_WR_ADDR_BRK = 0 PARAMETER C_INTERRUPT_IS_EDGE = 1 PARAMETER C_EDGE_IS_POSITIVE = 1 PARAMETER C_FSL_LINKS = 1 PARAMETER C_USE_MSR_INSTR = 1 BUS_INTERFACE DLMB = dlmb BUS_INTERFACE ILMB = ilmb BUS_INTERFACE DOPB = mb_opb BUS_INTERFACE IOPB = mb_opb PORT CLK = sys_clk_s PORT FSL0_S_CLK = fsl0_s_clk PORT FSL0_S_DATA = fsl0_s_data PORT FSL0_S_EXISTS = fsl0_s_exists PORT FSL0_S_READ = fsl0_s_read PORT Interrupt = ext_interrupt END BEGIN opb_v20 PARAMETER INSTANCE = mb_opb PARAMETER HW_VER = 1.10.c PARAMETER C_EXT_RESET_HIGH = 1 PORT SYS_Rst = sys_rst_s PORT OPB_Clk = sys_clk_s END BEGIN lmb_v10 PARAMETER INSTANCE = ilmb PARAMETER HW_VER = 1.00.a PARAMETER C_EXT_RESET_HIGH = 1 PORT SYS_Rst = sys_rst_s PORT LMB_Clk = sys_clk_s END BEGIN lmb_v10 PARAMETER INSTANCE = dlmb PARAMETER HW_VER = 1.00.a PARAMETER C_EXT_RESET_HIGH = 1 PORT SYS_Rst = sys_rst_s PORT LMB_Clk = sys_clk_s END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = dlmb_cntlr PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00003fff BUS_INTERFACE SLMB = dlmb BUS_INTERFACE BRAM_PORT = dlmb_port END BEGIN lmb_bram_if_cntlr PARAMETER INSTANCE = ilmb_cntlr PARAMETER HW_VER = 1.00.b PARAMETER C_BASEADDR = 0x00000000 PARAMETER C_HIGHADDR = 0x00003fff BUS_INTERFACE SLMB = ilmb BUS_INTERFACE BRAM_PORT = ilmb_port END BEGIN bram_block PARAMETER INSTANCE = lmb_bram PARAMETER HW_VER = 1.00.a PARAMETER C_MEMSIZE = 16384 BUS_INTERFACE PORTA = ilmb_port BUS_INTERFACE PORTB = dlmb_port END BEGIN opb_gpio PARAMETER INSTANCE = LEDs_8Bit PARAMETER HW_VER = 3.01.b PARAMETER C_GPIO_WIDTH = 8 PARAMETER C_IS_DUAL = 0 PARAMETER C_IS_BIDIR = 0 PARAMETER C_ALL_INPUTS = 0 PARAMETER C_BASEADDR = 0x40020000 PARAMETER C_HIGHADDR = 0x4002ffff BUS_INTERFACE SOPB = mb_opb PORT OPB_Clk = sys_clk_s PORT GPIO_d_out = fpga_0_LEDs_8Bit_GPIO_d_out END BEGIN opb_gpio PARAMETER INSTANCE = Push_Buttons_3Bit PARAMETER HW_VER = 3.01.b PARAMETER C_GPIO_WIDTH = 1 PARAMETER C_IS_DUAL = 0 PARAMETER C_IS_BIDIR = 0 PARAMETER C_ALL_INPUTS = 1 PARAMETER C_BASEADDR = 0x40000000 PARAMETER C_HIGHADDR = 0x4000ffff PARAMETER C_INTERRUPT_PRESENT = 1 BUS_INTERFACE SOPB = mb_opb PORT OPB_Clk = sys_clk_s PORT GPIO_in = fpga_0_Push_Buttons_3Bit_GPIO_in PORT IP2INTC_Irpt = Push_Buttons_3Bit_IP2INTC_Irpt END BEGIN dcm_module PARAMETER INSTANCE = dcm_0 PARAMETER HW_VER = 1.00.a PARAMETER C_CLK0_BUF = TRUE PARAMETER C_CLKIN_PERIOD = 20.000000 PARAMETER C_CLK_FEEDBACK = 1X PARAMETER C_EXT_RESET_HIGH = 1 PORT CLKIN = dcm_clk_s PORT CLK0 = sys_clk_s PORT CLKFB = sys_clk_s PORT RST = net_gnd PORT LOCKED = dcm_0_lock END BEGIN fsl_v20 PARAMETER INSTANCE = my_fsl_incoming PARAMETER HW_VER = 2.00.a PARAMETER C_USE_CONTROL = 0 PORT SYS_Rst = sys_rst_s PORT FSL_CLK = dcm_clk_s PORT FSL_S_CLK = fsl0_s_clk PORT FSL_S_DATA = fsl0_s_data PORT FSL_S_EXISTS = fsl0_s_exists PORT FSL_S_READ = fsl0_s_read PORT FSL_M_Clk = FSL0_M_Clk PORT FSL_M_Data = FSL0_M_Data PORT FSL_M_Write = FSL0_M_Write PORT FSL_M_Full = FSL0_M_Full ENDArticle: 100319
anyone played with connecting GB camera to an FPGA? RichArticle: 100320
mk wrote:
> Do you have a reference for this ?
My only reference is a vivid memory
of a sore experience. But since I made
a big deal out of it, I fired up Quartus 5.1 to check.
The default for unused pins is now
/As output driving GND/
which could still be a rude surprise
when powering up an new prototype.
The old default setting is still available:
/As output driving an unspecified signal/
Don't know what this could be good for.
Routing maybe.
A safer default would be
/As input tri-stated/
-- Mike Treseler
Article: 100321On Thu, 06 Apr 2006 13:47:05 -0700, Mike Treseler <mike_treseler@comcast.net> wrote: >A safer default would be >/As input tri-stated/ Only with a weak pull-down. I don't want to think about what hundreds of tri-stated floating inputs would do (ala when you try a small design on an off-the-shelf board)Article: 100322
Hi - Hmm.. Speaking for PlanAhead, this is a setup that we definitely do not test on. Not sure if I can help you, but answers to a couple of our questions may give us a clue: 1. Are you running on a notebook? 2. Does it hang consistently or semi-repeatably? If so, how? CPU remains idle or is it pegged? BTW, can you download 8.1.5 at www.xilinx.com/planahead and see if you still get this problem? Thanks Salil Raje, Ph.D Software Development Director, PlanAhead Xilinx Inc. "Ben Jones" <ben.jones@xilinx.com> wrote in message news:e10enr$hla1@cliff.xsj.xilinx.com... > Hi Sylvain, > > "Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote in > message news:1144237213.879794.79360@e56g2000cwe.googlegroups.com... > > - ISE Foundation 8.1 sp 3 > > - Chipscope 8.1.03 > > - PlanAhead 8.1.2 > > The JVM is each time provided with theses tools. It's the sun jre 1.5.0 > > but i'm not sure of the revision. > > I've tried with the latest sun jre as well with the same effects and > > blackdown jre is only 1.4.2 and doesn't work at all (normal, its not a > > 1.5) > > Interesting. I guess you can run other Java apps without any problems, > right? > If this were Windows I'd probably diagnose that as some manifestation of DLL > hell, but I don't usually have problems like that with Linux. Maybe there is > a Java guru around somewhere who would know better... > > > > I don't know why but each time I try to open a webcase, I get a "Server > > Error" page at url : > > > > https://xapps2.xilinx.com/websupport/clearexp_cgi/?login=Login > > Curious. I got a login prompt. > > > > Actually, I'd disagree. Certainly Coregen as of ISE 8.1i is a native > > > application, with only small amounts of Java for legacy core GUIs. > You're > > > right about the other two though. But there is certainly no policy at > work > > > to increase the amount of Java used (if anything, the reverse is true). > > Well, ok it may not be a policy. But it's still a fact ;) > > Touché. :-) > > > Indeed coregen has only some "ip customizer" but one of it is the v4 fx > > emac wrapper ;) And besides that, it works well. I can work with > > chipscope running on a remote machine using windows remote desktop and > > launching the cs_server.sh on my local machine. But for plan ahead it's > > a whole lot more annoying. > > And the weird thing is I never noticed that behavior in 7.1 ... > > Was that on the same gentoo system (i.e. did you just upgrade and now > everything is borked)? > > Looking at the answers database it appears that in 7.1i there were some > problems with multi-threading in the Linux JNI that caused the GUIs to > freeze during core generation (because the UI thread had to be disabled). > This didn't actually cause anything to freeze indefinitely though (it would > come back when the core had been generated). Perhaps it's somehow related to > that? Hard to tell. > > Cheers, > > -Ben- > >Article: 100323
"Felix Bertram" <flx@bertram-family.com> wrote in message news:49l64gFp3eu7U1@individual.net... > > I agree the software is complicated. (Way too complicated in my opinion.) > > if "software" is referring to the firmware: this is really not too > complicated. Have a look here: > * www.usb-by-example.com > * www.lvr.com > > > But all the solutions out there seem to be built around a little 8-bit > > micro. You don't think it's silly to have a 10 million gate FPGA sitting > > next to an 8051? > > disagreed. There are two types of data to be very clearly separated: > > * asynchronous data: this is all the USB device enumeration and control > stuff. This is low bandwidth, most of it happens only during device > attachment, and this is quite simple. An 8051 is still too complex to > handle this, there are designs out there using a simple state machine. > > * isochronous data: this is all the traffic your application requires. > In case you are streaming high bandwidth data and you need to do some > processing on it, an FPGA might be a good solution. You will usually not > want to pass 480Mbps of data through a CPU. Think of audio or video > applications, USB protocol analyzers, ... > > > Any comments welcome, > best regards, > > > Felix > -- > Dipl.-Ing. Felix Bertram > http://www.bertram-family.com/felix I guess my point was if you look at an fx2, for example, all I see is an 8-bit micro, a little bit of memory, and some relatively simple fifo hardware. All of this seems trivial inside a virtex-4, yet most v4 designs I've seen have the usb outside the fpga. Maybe that's so they can load the fpga at power up but it seems like if they have flash memory anyway, there's no real advantage to usb outside the fpga. -ClarkArticle: 100324
All, When we recently did a USB interface to the FPGA, we looked at the USB interface parts that were out there, their features, and their costs. We decided on a complete module (connector, and all) just because it was - 1. incredibly cheap, 2. useful (it has its own 8 bit uP to take care of everything we would ever need), and 3. it is done, and working (one less thing to do). Tightly integrating the USB into the FPGA has about 0 benefit. It is not like having an ethernet port, or a 6.25 Gbs serial link, or PCI express, or any of a number of high bandwidth interfaces where tight coupling just makes sense. I think there are some interfaces that don't qualify for inclusion in the high end FPGA families (like Virtex and its brothers). At the high end, you want the best performance for the least cost. Costs are assigned to the different categories of performance, with the most money being spent on the device(s) that deliver the biggest punch. The USB port is way down the list here. Maybe these sorts of interfaces are more suitable in the Spartan line, where speed is relatively unimportant, and where total cost is everything. Austin
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