Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi I've seen this before. The reason what that the current V5 controllers do not support SODIMMs. This feature is going to be added in one of the upcoming releases of MIG. For now the controller needs to be changed a little bit: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=25040 I hope this helps. JacoArticle: 124301
Hmm. Your definition of a state machine differs from established FSM theory. You focus only on the textual description. With your definition a CPU-core and its ROM is not a state machine. Also a shift register used to control other logic would not be a state machine. Any script generated state machines also do not count. Self resetting state machine (JTAG controller anyone?) are also no state machines because there is no reset signal. The definition of a state machine that I am used to is: A set of storage elements that are connected in a way that the following state of the elements depends on the previous state. State machines can be arbitrarily partitionend and merged. The whole chip can be analyzed as one big state machine (usually not a big idea) or each individual flip-flop can be interpreted as a state machine (also often a bad idea). But to give you the benefit of doubt and return to your orginal question: Smith-Waterman hardware implementations instantiate tens of thousands of identical state machines. Oh, wait, the implentation that we used had not reset. Damn. Kolja Sulimma On 17 Sep., 21:43, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi Glen, > There is a theory behind to resolve the problem. > > A state machine can be defined in such a scentific way: > 1. All states in a state machine have their own names; > 2. All states in a state machine are mutually exclusive; > 3. Only one state is active in any cycle; > 4. The number of states in a state machine must be 2 or more; > 5. There must have either asynchronous or a synchronous reset signal > for the state machine and after their assertion, the state machine > must be in initial state. > > I guess there are less than 27 engineers in the world who have the > experiences to do the designs. > > If your experiences are fully in FPGA and VHDL worlds, you may never > have a chance to get a right guess with any possible wildest > imagination, > > Any more question? > > WengArticle: 124302
hmm, but that is not the order of my truth table. i want to have something like this: 0000 0101 0101 0101 A1 A2 A3 A4 (A1+A2)*A4 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 1 1 0 0 1 0 0 0 0 1 0 1 1 0 1 1 0 0 0 1 1 1 1 1 0 0 0 0 1 0 0 1 1 1 0 1 0 0 1 0 1 1 1 1 1 0 0 0 1 1 0 1 1 1 1 1 0 0 1 1 1 1 1Article: 124303
fastgreen2000@yahoo.com writes: > Hi - Can someone point me to where FVAL, LVAL, DVAL relationship > requirements are? > I look at the i/f spec on alacron.com, but it doesn't list any. I don't think there are any. I've always assumed not - just do something like: * Once FVAL has gone high, you are ready to start a frame. * When LVAL has gone high (which may be in the same cycle as FVAL going high) you have the start of a line., set X to 0. If waiting for start of frame, set Y to 0 also, otherwise incrememnt Y * Whenever DVAL is high, increment X, and do something useful with the data. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 124304
Maki, If you are thinking CODE REUSE, write using MUX ! The new devices from Xilinx and other vendors do not include the long Tri-state lines -> So write using MUX ! Laurent www.amontec.com wrote: > RCIngham wrote: > >>>Hi, im implementing a 16bit bus along the lines of AMBA APB for some >>>of my peripherals like IDE ATA controller, LCD dsplay controller, ftdi >>>usb interface etc. But i found that xilinx spartan devices have no >>>internal tristate buffers. >>>I have a dozen or more peripherals to connect. Any idea of how i can >>>implement this? >>> >>>thanks, >>>aravind >> >>Use multiplexers. Internal tristate buses are deprecated in ASIC designs, >>and - most wisely, IMHO - not possible in FPGA designs. > > > Possible - Yes. But big and slow therefore depreciated. > You can code tristate buses and most tolls will emulate them with > multiplexers. > > Regards, > Maki >Article: 124305
On 18 Sep, 07:33, aravind <aramos...@gmail.com> wrote: > Hi, im implementing a 16bit bus along the lines of AMBA APB for some > of my peripherals like IDE ATA controller, LCD dsplay controller, ftdi > usb interface etc. But i found that xilinx spartan devices have no > internal tristate buffers. > I have a dozen or more peripherals to connect. Any idea of how i can > implement this? > > thanks, > aravind As the others have said, use muxes on chip. Also, doesn't AMBA APB uses muxes anyway? Cheers, JonArticle: 124306
Hello All, there is a 32bit Data Bram. I am trying to load a 32 bits data in the fourth location (4) of the Bram (0-255 locations). The addresses are : Address Map for Processor ppc405_0 (0b0000010000-0b0000010011) ppc405_0 (0b0000100000-0b0000100011) ppc405_0 (0x40000000-0x40007fff) docm_cntlr docm (0x80000000-0x8000ffff) LEDs_16Bit plb (0xffff8000-0xffffffff) iocm_cntlr iocm In order to load the 32 bit data in the fourth location of the Dataside Bram the given address for this location from my testbench will be the address<= "0000000000000000000000000000100" (location 4) or should be given as address <= "1000000000000000000000000000100" [(0x40000004]? regardsArticle: 124307
On Sep 18, 11:27 am, "jacob...@xilinx.com" <naude.j...@gmail.com> wrote: > Hi > > I've seen this before. The reason what that the current V5 controllers > do not support SODIMMs. This feature is going to be added in one of > the upcoming releases of MIG. > > For now the controller needs to be changed a little bit:http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountry... > > I hope this helps. > Jaco Actually I don't think it's the issue described here. I think the problem is in the tools. When putting an oserdes followed by a differential output buffer, the tool duplicate itself the oserdes so that you have two serdes and two output buffer. But it somehow does it wrong and the duplicated oserdes is not always in sync ... When you manually do the duplication, it works fine. SylvainArticle: 124308
"Jon Beniston" <jon@beniston.com> wrote in message news:1190118672.383645.211380@d55g2000hsg.googlegroups.com... > On 18 Sep, 07:33, aravind <aramos...@gmail.com> wrote: >> Hi, im implementing a 16bit bus along the lines of AMBA APB for some >> of my peripherals like IDE ATA controller, LCD dsplay controller, ftdi >> usb interface etc. But i found that xilinx spartan devices have no >> internal tristate buffers. >> I have a dozen or more peripherals to connect. Any idea of how i can >> implement this? >> >> thanks, >> aravind > > As the others have said, use muxes on chip. Also, doesn't AMBA APB > uses muxes anyway? > > Cheers, > Jon > APB uses uni-directional read and write databusses. MikeArticle: 124309
On Sep 18, 6:36 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > fastgreen2...@yahoo.com writes: > > Hi - Can someone point me to where FVAL, LVAL, DVAL relationship > > requirements are? > > I look at the i/f spec on alacron.com, but it doesn't list any. > > I don't think there are any. I've always assumed not - just do > something like: > > * Once FVAL has gone high, you are ready to start a frame. > * When LVAL has gone high (which may be in the same cycle as FVAL going > high) you have the start of a line., set X to 0. If waiting for start > of frame, set Y to 0 also, otherwise incrememnt Y > * Whenever DVAL is high, increment X, and do something useful with the > data. > > Cheers, > Martin > > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html It gets more complex than that depending on the camera. I find it is safest to use (not LVAL) as a clock enable for FVAL. There are some cameras that allow FVAL to go inactive before the end of the last line of the frame. Also you need to be able to selectively ignore DVAL. Some cameras do not provide this signal, others only assert it during LVAL, so you can't use it as a clock enable for the control signals. There is no minimum specification for FVAL to LVAL assertion. Assume they can go active on the same cycle. Also assume there is no maximum FVAL to LVAL timing. Furthermore LVAL may or may not be asserted between frames while FVAL is low. And of course last but not least, there is a "Basler" extension to the Full Camera Link spec that allows 80 bits of data per clock (Camera Link only goes up to 64 bits) by completely re-numbering the data outputs and only replicating the LVAL signal on the 2nd and 3rd Channel-Links. You also lose the DVAL and SPARE signals in this mode, and FVAL is only on the first Channel-Link. Basler is no longer the only camera maker to use this mode. HTH, GaborArticle: 124310
On Sep 18, 9:21 am, Gabor <ga...@alacron.com> wrote: > On Sep 18, 6:36 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > > > > > fastgreen2...@yahoo.com writes: > > > Hi - Can someone point me to where FVAL, LVAL, DVAL relationship > > > requirements are? > > > I look at the i/f spec on alacron.com, but it doesn't list any. > > > I don't think there are any. I've always assumed not - just do > > something like: > > > * Once FVAL has gone high, you are ready to start a frame. > > * When LVAL has gone high (which may be in the same cycle as FVAL going > > high) you have the start of a line., set X to 0. If waiting for start > > of frame, set Y to 0 also, otherwise incrememnt Y > > * Whenever DVAL is high, increment X, and do something useful with the > > data. > > > Cheers, > > Martin > > > -- > > martin.j.thomp...@trw.com > > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html > > It gets more complex than that depending on the camera. > I find it is safest to use (not LVAL) as a clock enable > for FVAL. There are some cameras that allow FVAL to go > inactive before the end of the last line of the frame. > Also you need to be able to selectively ignore DVAL. > Some cameras do not provide this signal, others only assert > it during LVAL, so you can't use it as a clock enable > for the control signals. > > There is no minimum specification for FVAL to LVAL > assertion. Assume they can go active on the same > cycle. Also assume there is no maximum FVAL to > LVAL timing. Furthermore LVAL may or may not be > asserted between frames while FVAL is low. > > And of course last but not least, there is a "Basler" > extension to the Full Camera Link spec that allows > 80 bits of data per clock (Camera Link only goes up > to 64 bits) by completely re-numbering the data > outputs and only replicating the LVAL signal on > the 2nd and 3rd Channel-Links. You also lose the > DVAL and SPARE signals in this mode, and FVAL is > only on the first Channel-Link. Basler is no > longer the only camera maker to use this mode. > > HTH, > Gabor Another point. If you are designing a camera, or camera-like device you intend to hook to a framegrabber, it helps to make these signals well-behaved as follows: 1) Don't use DVAL as a data enable unless you need to reduce your clock speed below the Channel link minimum. Many framegrabbers expect data on every clock during LVAL. The best approach is to tie DVAL high. 2) Allow several clock cycles from assertion of FVAL to assertion of LVAL for the first line. Leave FVAL asserted until a few cycles after deassertion of LVAL for the last line. 3) Don't assert LVAL while FVAL is deasserted. 4) Make all lines (assertion period of LVAL) the same length. If your data does not represent a rectangular array, re- format it to fit this. 5) Provide the same number of lines in each frame. You can violate any of these rules as necessary, but realize that for each one you violate your list of compatible framegrabbers gets shorter.Article: 124311
Gabor <gabor@alacron.com> writes: > > It gets more complex than that depending on the camera. > I find it is safest to use (not LVAL) as a clock enable > for FVAL. There are some cameras that allow FVAL to go > inactive before the end of the last line of the frame. Ooh, fun - I haven't seen one of those! > Also you need to be able to selectively ignore DVAL. > Some cameras do not provide this signal, others only assert > it during LVAL, so you can't use it as a clock enable > for the control signals. > True. > There is no minimum specification for FVAL to LVAL > assertion. Assume they can go active on the same > cycle. Also assume there is no maximum FVAL to > LVAL timing. Furthermore LVAL may or may not be > asserted between frames while FVAL is low. > And I recall a JAI camera which had LVAL and FVAL active low! > And of course last but not least, there is a "Basler" > extension to the Full Camera Link spec that allows > 80 bits of data per clock (Camera Link only goes up > to 64 bits) by completely re-numbering the data > outputs and only replicating the LVAL signal on > the 2nd and 3rd Channel-Links. You also lose the > DVAL and SPARE signals in this mode, and FVAL is > only on the first Channel-Link. Basler is no > longer the only camera maker to use this mode. > Maybe I'll look at Firewire for our next camera interface :-) Any decent link layer/phy combined chips out there which I can get in prototyping volumes and haven't got to mess with PCI for? Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 124312
<lembke.stefan@googlemail.com> wrote in message news:1190109289.217552.175550@57g2000hsv.googlegroups.com... > hmm, but that is not the order of my truth table. i want to have > something like this: 0000 0101 0101 0101 > > A1 A2 A3 A4 (A1+A2)*A4 > 0 0 0 0 0 > 0 0 0 1 0 > 0 0 1 0 0 > 0 0 1 1 0 > 0 1 0 0 0 > 0 1 0 1 1 > 0 1 1 0 0 > 0 1 1 1 1 > 1 0 0 0 0 > 1 0 0 1 1 > 1 0 1 0 0 > 1 0 1 1 1 > 1 1 0 0 0 > 1 1 0 1 1 > 1 1 1 0 0 > 1 1 1 1 1 > Hi Stefan, Which is the same as this:- A4 A3 A2 A1 (A1+A2)*A4 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 0 1 1 0 0 1 0 0 0 0 1 0 1 0 0 1 1 0 0 0 1 1 1 0 1 0 0 0 0 1 0 0 1 1 1 0 1 0 1 1 0 1 1 1 1 1 0 0 0 1 1 0 1 1 1 1 1 0 1 1 1 1 1 1 Try drinking more coffee! ;-) Cheers, Syms.Article: 124313
> Another point. If you are designing a camera, or camera-like > device you intend to hook to a framegrabber, it helps to > make these signals well-behaved as follows: I'm doing exactly that - sending video data as if I'm the camera, to the frame grabber. > > 1) Don't use DVAL as a data enable unless you need to reduce > your clock speed below the Channel link minimum. Many > framegrabbers expect data on every clock during LVAL. The > best approach is to tie DVAL high. > > 2) Allow several clock cycles from assertion of FVAL to > assertion of LVAL for the first line. Leave FVAL asserted > until a few cycles after deassertion of LVAL for the > last line. > > 3) Don't assert LVAL while FVAL is deasserted. > > 4) Make all lines (assertion period of LVAL) the same length. > If your data does not represent a rectangular array, re- > format it to fit this. > > 5) Provide the same number of lines in each frame. > > You can violate any of these rules as necessary, but > realize that for each one you violate your list > of compatible framegrabbers gets shorter. The only thing I'm not doing is #2 above. All my valids line up, LVAL and DVAL identical. All transitions occur at the rising edge of CLK. I guess it's time to call the frame grabber maker... Thanks.Article: 124314
Hi, Since the initial rash of AES / Rijndael cores a few years ago, I haven't seen much research at the high speed end. Does anyone know how low the latency is for a recent high-end core in a current FPGA family? A quick web search reveals plenty of heavily pipelined implementations with poor latency, but none that are really quick in terms of latency. Thanks, AllanArticle: 124315
vasile wrote: > On Sep 17, 10:39 am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >> vasile wrote: >>> Hi to everybody, >>> I'ts not very clear from the Virtex 5 User guide, Clock resources >>> chapter if it's possible to route (on different GCLK inputs) single >>> ended and differential CLKs. Then at configuration time use either the >>> single ended clock (routed at the P side of the differential input >>> pair) or differential clock (say LVDS clock). >>> User manual say: "The 20 global clock pins on Virtex-5 devices can be >>> connected to 20 differential or 20 singleended board clocks" >>> page20-21 and "Each clock input can be either single-ended or >>> differential" page 20. That means only either single ended either >>> differential clock is allowed? >>> The second question is about differential clocks routed to XY GTP >>> transcievers. Can those be used safely as GCLK or RCLK for the GTP >>> opposite banks (banks far away from the GTPs) or an outer clock must >>> be routed on PCB? >> You are misinterpreting the documentation. A clock circuit is made >> up of multiple resources including an package input pin (IBUF or IBUFDS), >> an optional DCM or PLL and a global clock tree (BUFG). >> >> The paragraph that you quoted was discussing that the package input pin >> could be either single ended (LVCMOS, SSTL, HSTL, etc) or differential >> (LVDS). These package pins would be connected to a physical on board >> clock device that outputs a specific signaling standard. A >> >> The MGTREFCLK input pins are intended only for use with the RocketIO >> transceivers. These can be driven into the array, but it must be done >> through an instantiated RocketIO and the only allowed connection from >> here is to a BUFG. It is not recommended to use these pins for anything >> other than RocketIO based designs. In particular you would not want to >> use these pins for system synchronous designs as the timing is not the >> same as defined clock input pins. >> > > OK, thank you, this is answering just to a part of my question. > Can I route both differential and single ended clocks to the same GCLK > dedicated bank (like bank3 in LX330T ) and use both of them (one is > LVDS as you say and the other is single ended 2.5V clock) ? > Where can I found this info in the datasheet please, so I will not > misinterpreting anymore ? > The clock input pins are independently configurable just like the other IOs, so yes you can have both single ended and differential inputs in bank 3. The limitations on what IO standards can be used at the same time in this bank is the same as for all other banks. Ed McGettigan -- Xilinx Inc.Article: 124316
On Sep 18, 5:35 pm, Allan Herriman <allanherri...@hotmail.com> wrote: > Hi, > > Since the initial rash of AES / Rijndael cores a few years ago, I > haven't seen much research at the high speed end. > > Does anyone know how low the latency is for a recent high-end core in > a current FPGA family? > A quick web search reveals plenty of heavily pipelined implementations > with poor latency, but none that are really quick in terms of latency. > > Thanks, > Allan What kind of frequency / latency are you looking for ? Most core can pretty easily be "de-pipelinined" to diminish latency but degrade frequency ... SylvainArticle: 124317
Hi,
Couple of months ago there was a question about TimeQuest clock naming.
dervie_pll_clocks generates some cryptic names, which are not wanted, and
doing manually create_generated_clock is also time-consuming and
error-prune.
The solution to this could be:
create_clock -name primary_clock ...
derive_pll_clocks
create_generated_clock -name myclock -source [get_ports
{my_clock_ouput_pin}]
Las line creates a clock, which has clock source by the desing. If
my_clock_output_pin is replica of pll_clock, then the generated clock has
the same properties, automatically, without any cryptic clock names, with
smaller propability of manual error.
--
Topi
Article: 124318>On 13 Set, 14:21, "MJ Pearson" <mjp...@york.ac.uk> wrote: >> Hello, >> >> I am using the xilinx virtex II development board xupv2p. I have built an >> expansion board that connects to the high speed expansion port, and >> delivers information from a camera. In ISE, I have produced what I think >> is a working piece of vhdl to synchronise the camera data (there will be 2 >> data sets incoming) to the FPGA clock. >> >> What I would like to do is just read out this incoming data so I can check >> it. My idea was to use a microblaze processor - I will need one to do some >> processing at a later stage, and just do a printf to write the data to >> hyper-terminal. >> >> I used the create / import peripheral wizard, and have been hacking the >> user_logic file to incorporate my synchronization design. I am a bit >> unsure of ports though - do I have any user ports - are these the input >> pins??? I have altered the UCF file to assign the pins of the expansion >> port to my inputs in my vhdl file. Should I write this data to a slave >> register?? >> >> Then in my C file, is it just a simple read and printf procedure. >> >> Any help / ideas I'd be grateful, >> >> Thanks >> >> Marc. > >Hi, >I don't know if I have understood your point but it seems to me that >you want to print data coming from a camera. > >If so, you should create a peripheral (like you have already done) >with some SW registers. This registers are the interface between the >peripheral and the microcontroller. The additional ports of your >peripheral will be the interface between the peripheral itself and the >camera. >So your IP, once acquired the desired data, should write something to >a register so that you can read it from the microprocessor. Probably >you also need to write a simple driver (in C language) to find if >there's someting new in the register, read the register and so on (the >driver isn't strictly necessary). >Googoling around you'll find all the details. > >Hope this help a little. > >Andrea > > Thanks for the reply. Have got (a little) further with this.... I have made a number of external input ports for the inputs from my camera(s). I have altered the ucf file, mpd, mhs... I used the create / import peripheral wizard, and as mentioned have altered the user_logic.vhdl file. Do I need to map my external ports on the peripheral .vhdl file (created by the wizard)? I get an error when I build the netlist: ERROR:MDT - HDL synthesis failed! INFO:MDT - Refer to C:\MATLAB\R2006a\work\edkStuff\periphWizard\synthesis\camtoleds_0_wrapper_xst .srp for details ERROR:MDT - platgen failed with errors! Looking at the .srp file : Formal CAM1_I_0 of entity with no default value must be associated with an actual value. CAM1_I_0 is an input port in my user logic .vhdl file. Which I have (think I have) mapped to an external pin via my ucf file: UCF snippet: NET "CAM_IN_0_pin" LOC = "AE5"; NET "CAM_IN_0_pin" IOSTANDARD = LVTTL; MHS: PORT CAM1_I_0 = CAM_IN_0 mpd: PORT CAM1_I_0 = "", DIR = I Sorry if all this sounds pathetic, I have no idea how to fix that error, I am a bit lost!!Article: 124319
Hi, 1. I am talking about GUESSING the largest number of state machines a current finished design may have. Not ceiling. 2. State machine can be anything, my definition is only for reference to clear up any misunderstanding. 3. A synchronous or an asynchronous reset signal is vital, either with clear routing or a hidden within other procedures. WengArticle: 124320
Has anyone got any example Verilog code for this? I'm currently using Quartus wizard generated code and wrapping it up in a Verilog module so I can use my own parameters instead of running the wizard each time I need a new variation (which is a complete pain). I thought that perhaps inferring the memory might yield better and more efficient results. Ta.Article: 124321
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1190135851.404698.228480@y42g2000hsy.googlegroups.com... > Hi, > 1. I am talking about GUESSING the largest number of state machines a > current finished design may have. Not ceiling. My official guess: light blue.Article: 124322
glen herrmannsfeldt wrote: > I thought the tools would synthesize the appropriate MUX given > tristate buffer logic. They probably do that better than > explicitly programmed MUX logic. I would expect the same utilization for either description. The question is which description is easier for the designer to write and test. That of course, depends on the designer. -- Mike TreselerArticle: 124323
Weng Tianxiang wrote: (snip) > 3. A synchronous or an asynchronous reset signal is vital, either with > clear routing or a hidden within other procedures. I disagree. Some can synchronize without any reset signal, though they may have one anyway. The receiver in a UART, if started out of frame, will synchronize to frame boundaries after not so many characters come through. That is the purpose for start/stop bits. There are many systems with a large number of self synchronizing state machines. -- glenArticle: 124324
Amontec, Larry wrote: > If you are thinking CODE REUSE, write using MUX ! > The new devices from Xilinx and other vendors do not include the long > Tri-state lines -> So write using MUX ! I thought the tools would synthesize the appropriate MUX given tristate buffer logic. They probably do that better than explicitly programmed MUX logic. -- 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