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 all, I'm working on a project to create a basic FPGA based digital cinema camera. The FPGA would have to capture a 1920x1080 progressive frames at speeds from 1 to 60 frames/second from a Kodak CCD we've already chosen, convert the stream to a DNG sequence (separate Adobe DNG files, you can find the SDK at www.adobe.com) and store them in an internal SATA SSD disk. The FPGA also needs to control every single feature in the sensor with a basic user interface, enable a DVI out for monitoring and a USB in/out so the files can be downloaded to a computer. This is of course a paid job.Article: 136876
On Dec 10, 11:43=A0am, Rob <robns...@frontiernet.net> wrote: > > There are no asynchronous inputs. =A0All the inputs are sync'd to the > incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock is > for something completely unrelated and has nothing to do with the SM. > > Rob- Hide quoted text - > Maybe add a free running counter that is clocked by the 6kHz clock that counts from 0 to 24 and then goes back to 0 resetting it only during powerup. Bring the counter out to debug pins. If your original hypothesis is correct that "...there is a spurious edge which my SM reacts to, thus causing erroneous data to be latched." then this counter would at some point end up at a non-zero count between transmissions (I'm assuming here that the transmissions are not continuous and there are identifiable gaps in time during which the state machine is waiting for the next 25 clock transmission to occur). With that setup you can also look for times when the counter changes states quicker than the expected 6 kHz rate. It can be a tad difficult depending on what equipment you can bring to bear and how many debug pins you have in your FPGA, but at least it gives you a direct view of flops inside the device that are being clocked and that will change state with every clock. Building somewhat further on that approach, if the state machine already has a signal that identifies the 'waiting for a new transmission to occur' time, then you could gate that signal with the counter being 0 and simply output a '1' when the protocol has been broken. That gives you one specific signal to monitor to trigger the scope. Either of those approaches though is only meant to give you a known reliable trigger mechanism for a scope or logic analyzer so you can investigate further (if it triggers) or reject your hypothesis (if it does not). It's also not really clear whether you have such a trigger condition or if you're relying on perhaps some higher level system observation instead. Your original thought to build a pulse monitor was somewhat along these lines, the problem with that approach though is that you're jumping to a solution that has holes to it. Even if your hypothesis is correct you haven't actually verified the root cause problem. Kevin JenningsArticle: 136877
On Dec 10, 10:04 am, ooz...@gmail.com wrote: > Hi all, > > I'm working on a project to create a basic FPGA based digital > cinema camera. The FPGA would have to capture a 1920x1080 progressive > frames at speeds from 1 to 60 frames/second from a Kodak CCD we've > already chosen, convert the stream to a DNG sequence (separate Adobe > DNG files, you can find the SDK atwww.adobe.com) and store them in an > internal SATA SSD disk. > > The FPGA also needs to control every single feature in the sensor > with a basic user interface, enable a DVI out for monitoring and a USB > in/out so the files can be downloaded to a computer. > > This is of course a paid job. 1) You didn't say where the work will be done. USENET is global, remember? 2) This of course is NOT a job posting board.Article: 136878
On Dec 10, 12:14=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > On Dec 10, 11:43=A0am, Rob <robns...@frontiernet.net> wrote: > > > > > There are no asynchronous inputs. =A0All the inputs are sync'd to the > > incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock is > > for something completely unrelated and has nothing to do with the SM. > > > Rob- Hide quoted text - > > Maybe add a free running counter that is clocked by the 6kHz clock > that counts from 0 to 24 and then goes back to 0 resetting it only > during powerup. =A0Bring the counter out to debug pins. =A0If your > original hypothesis is correct that "...there is a spurious edge which > my SM reacts to, thus causing erroneous data to be latched." then this > counter would at some point end up at a non-zero count between > transmissions (I'm assuming here that the transmissions are not > continuous and there are identifiable gaps in time during which the > state machine is waiting for the next 25 clock transmission to > occur). =A0With that setup you can also look for times when the counter > changes states quicker than the expected 6 kHz rate. =A0It can be a tad > difficult depending on what equipment you can bring to bear and how > many debug pins you have in your FPGA, but at least it gives you a > direct view of flops inside the device that are being clocked and that > will change state with every clock. I already have a counter (that counts from 0 to 24) tied to the incoming 6kHz clock. It is this counter that determines where I am in the serial stream; and thus determines which flop within my data register gets clocked with the incoming data. But yes, I have already thought about doing this. But I don't need to--read below. > > Building somewhat further on that approach, if the state machine > already has a signal that identifies the 'waiting for a new > transmission to occur' time, then you could gate that signal with the > counter being 0 and simply output a '1' when the protocol has been > broken. =A0That gives you one specific signal to monitor to trigger the > scope. > > Either of those approaches though is only meant to give you a known > reliable trigger mechanism for a scope or logic analyzer so you can > investigate further (if it triggers) or reject your hypothesis (if it > does not). > > It's also not really clear whether you have such a trigger condition > or if you're relying on perhaps some higher level system observation > instead. =A0Your original thought to build a pulse monitor was somewhat > along these lines, the problem with that approach though is that > you're jumping to a solution that has holes to it. =A0Even if your > hypothesis is correct you haven't actually verified the root cause > problem. > I did build the pulse monitor and the problem got worse. This of course told me that I must be fighting a timing that is on the hairy edge, as there is a slight delay through my "filter". So I started looking at the path in much more scrutiny and found a section of the placement that didn't have a lot of margin. I tightened this up and the problems have disappeared. This obviously makes more sense since I never saw any glitches/runts on the scope. And it also explains why some boards worked and some didn't. Again, I appreciate the dialogue....Article: 136879
Instead of complicated state machine to detect glitches or runt pulse, one can simply use the clock signal to toggle a T-flipflop. If you observer a pulse of shorter duration than expected then there is a glitch or a runt pulse. Use the 6Kz clock and divide it by 2 using a flipflop. Put no other loads on this clock like other than single flipflop. Bring out the divided clock to the output pin and observe on the scope. Set the trigger to trigger on any pulse less than time period of the 3KHz expected signal. If you get a pulse of shorter time period then you have a glitch or runt pulse. If the device has DDR registers than they would be ideal and you can get 6kHz output instead of 3 KHz. Brijesh On Dec 10, 1:05=A0pm, Rob <robns...@frontiernet.net> wrote: > On Dec 10, 12:14=A0pm, KJ <kkjenni...@sbcglobal.net> wrote: > > > > > On Dec 10, 11:43=A0am, Rob <robns...@frontiernet.net> wrote: > > > > There are no asynchronous inputs. =A0All the inputs are sync'd to the > > > incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock i= s > > > for something completely unrelated and has nothing to do with the SM. > > > > Rob- Hide quoted text - > > > Maybe add a free running counter that is clocked by the 6kHz clock > > that counts from 0 to 24 and then goes back to 0 resetting it only > > during powerup. =A0Bring the counter out to debug pins. =A0If your > > original hypothesis is correct that "...there is a spurious edge which > > my SM reacts to, thus causing erroneous data to be latched." then this > > counter would at some point end up at a non-zero count between > > transmissions (I'm assuming here that the transmissions are not > > continuous and there are identifiable gaps in time during which the > > state machine is waiting for the next 25 clock transmission to > > occur). =A0With that setup you can also look for times when the counter > > changes states quicker than the expected 6 kHz rate. =A0It can be a tad > > difficult depending on what equipment you can bring to bear and how > > many debug pins you have in your FPGA, but at least it gives you a > > direct view of flops inside the device that are being clocked and that > > will change state with every clock. > > I already have a counter (that counts from 0 to 24) tied to the > incoming 6kHz clock. It is this counter that determines where I am in > the serial stream; and thus determines which flop within my data > register gets clocked with the incoming data. =A0But yes, I have already > thought about doing this. =A0But I don't need to--read below. > > > > > > > Building somewhat further on that approach, if the state machine > > already has a signal that identifies the 'waiting for a new > > transmission to occur' time, then you could gate that signal with the > > counter being 0 and simply output a '1' when the protocol has been > > broken. =A0That gives you one specific signal to monitor to trigger the > > scope. > > > Either of those approaches though is only meant to give you a known > > reliable trigger mechanism for a scope or logic analyzer so you can > > investigate further (if it triggers) or reject your hypothesis (if it > > does not). > > > It's also not really clear whether you have such a trigger condition > > or if you're relying on perhaps some higher level system observation > > instead. =A0Your original thought to build a pulse monitor was somewhat > > along these lines, the problem with that approach though is that > > you're jumping to a solution that has holes to it. =A0Even if your > > hypothesis is correct you haven't actually verified the root cause > > problem. > > I did build the pulse monitor and the problem got worse. =A0This of > course told me that I must be fighting a timing that is on the hairy > edge, as there is a slight delay through my "filter". =A0So I started > looking at the path in much more scrutiny and found a section of the > placement that didn't have a lot of margin. =A0I tightened this up and > the problems have disappeared. =A0This obviously makes more sense since > I never saw any glitches/runts on the scope. =A0And it also explains why > some boards worked and some didn't. > > Again, I appreciate the dialogue....Article: 136880
Rob wrote: > On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote: > >>On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote: >> >> >> >> >>>There are no asynchronous inputs. All the inputs are sync'd to the >>>incoming slow 6kHz clock. The other fast internal FPGA MHz clock is >>>for something completely unrelated and has nothing to do with the SM. >> >>>Rob- Hide quoted text - >> >>Maybe add a free running counter that is clocked by the 6kHz clock >>that counts from 0 to 24 and then goes back to 0 resetting it only >>during powerup. Bring the counter out to debug pins. If your >>original hypothesis is correct that "...there is a spurious edge which >>my SM reacts to, thus causing erroneous data to be latched." then this >>counter would at some point end up at a non-zero count between >>transmissions (I'm assuming here that the transmissions are not >>continuous and there are identifiable gaps in time during which the >>state machine is waiting for the next 25 clock transmission to >>occur). With that setup you can also look for times when the counter >>changes states quicker than the expected 6 kHz rate. It can be a tad >>difficult depending on what equipment you can bring to bear and how >>many debug pins you have in your FPGA, but at least it gives you a >>direct view of flops inside the device that are being clocked and that >>will change state with every clock. > > > I already have a counter (that counts from 0 to 24) tied to the > incoming 6kHz clock. It is this counter that determines where I am in > the serial stream; and thus determines which flop within my data > register gets clocked with the incoming data. But yes, I have already > thought about doing this. But I don't need to--read below. > > > >>Building somewhat further on that approach, if the state machine >>already has a signal that identifies the 'waiting for a new >>transmission to occur' time, then you could gate that signal with the >>counter being 0 and simply output a '1' when the protocol has been >>broken. That gives you one specific signal to monitor to trigger the >>scope. >> >>Either of those approaches though is only meant to give you a known >>reliable trigger mechanism for a scope or logic analyzer so you can >>investigate further (if it triggers) or reject your hypothesis (if it >>does not). >> >>It's also not really clear whether you have such a trigger condition >>or if you're relying on perhaps some higher level system observation >>instead. Your original thought to build a pulse monitor was somewhat >>along these lines, the problem with that approach though is that >>you're jumping to a solution that has holes to it. Even if your >>hypothesis is correct you haven't actually verified the root cause >>problem. >> > > > I did build the pulse monitor and the problem got worse. This of > course told me that I must be fighting a timing that is on the hairy > edge, as there is a slight delay through my "filter". So I started > looking at the path in much more scrutiny and found a section of the > placement that didn't have a lot of margin. I tightened this up and > the problems have disappeared. This obviously makes more sense since > I never saw any glitches/runts on the scope. And it also explains why > some boards worked and some didn't. > > Again, I appreciate the dialogue.... > > If this is an issue of the relative timing of the clock and data as you note above, why not just take the data on the other edge of the clock where it is stable and there are no timing issues at all?Article: 136881
On Dec 10, 2:13=A0pm, doug <x...@xx.com> wrote: > Rob wrote: > > On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote: > > >>On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote: > > >>>There are no asynchronous inputs. =A0All the inputs are sync'd to the > >>>incoming slow 6kHz clock. =A0The other fast internal FPGA MHz clock is > >>>for something completely unrelated and has nothing to do with the SM. > > >>>Rob- Hide quoted text - > > >>Maybe add a free running counter that is clocked by the 6kHz clock > >>that counts from 0 to 24 and then goes back to 0 resetting it only > >>during powerup. =A0Bring the counter out to debug pins. =A0If your > >>original hypothesis is correct that "...there is a spurious edge which > >>my SM reacts to, thus causing erroneous data to be latched." then this > >>counter would at some point end up at a non-zero count between > >>transmissions (I'm assuming here that the transmissions are not > >>continuous and there are identifiable gaps in time during which the > >>state machine is waiting for the next 25 clock transmission to > >>occur). =A0With that setup you can also look for times when the counter > >>changes states quicker than the expected 6 kHz rate. =A0It can be a tad > >>difficult depending on what equipment you can bring to bear and how > >>many debug pins you have in your FPGA, but at least it gives you a > >>direct view of flops inside the device that are being clocked and that > >>will change state with every clock. > > > I already have a counter (that counts from 0 to 24) tied to the > > incoming 6kHz clock. It is this counter that determines where I am in > > the serial stream; and thus determines which flop within my data > > register gets clocked with the incoming data. =A0But yes, I have alread= y > > thought about doing this. =A0But I don't need to--read below. > > >>Building somewhat further on that approach, if the state machine > >>already has a signal that identifies the 'waiting for a new > >>transmission to occur' time, then you could gate that signal with the > >>counter being 0 and simply output a '1' when the protocol has been > >>broken. =A0That gives you one specific signal to monitor to trigger the > >>scope. > > >>Either of those approaches though is only meant to give you a known > >>reliable trigger mechanism for a scope or logic analyzer so you can > >>investigate further (if it triggers) or reject your hypothesis (if it > >>does not). > > >>It's also not really clear whether you have such a trigger condition > >>or if you're relying on perhaps some higher level system observation > >>instead. =A0Your original thought to build a pulse monitor was somewhat > >>along these lines, the problem with that approach though is that > >>you're jumping to a solution that has holes to it. =A0Even if your > >>hypothesis is correct you haven't actually verified the root cause > >>problem. > > > I did build the pulse monitor and the problem got worse. =A0This of > > course told me that I must be fighting a timing that is on the hairy > > edge, as there is a slight delay through my "filter". =A0So I started > > looking at the path in much more scrutiny and found a section of the > > placement that didn't have a lot of margin. =A0I tightened this up and > > the problems have disappeared. =A0This obviously makes more sense since > > I never saw any glitches/runts on the scope. =A0And it also explains wh= y > > some boards worked and some didn't. > > > Again, I appreciate the dialogue.... > > If this is an issue of the relative timing of the clock and data > as you note above, why not just take the data on the other edge > of the clock where it is stable and there are no timing issues > at all? The master sends out the data on the falling edge so one would think that since I'm using the rising edge of the clock that there would be plenty of tsu time.Article: 136882
Hello all, as a newbe with FPGAs I have no clue how to use the NPI interface of the MPMC from Xilinx. I haven't found a really good example. What I need is a simple module in VHDL which reads and writes the memory (maybe a simple memory test). Is there something available ??? Can someone help me out ? Thanks a lot! /HBArticle: 136883
Rob wrote: > On Dec 10, 2:13 pm, doug <x...@xx.com> wrote: > >>Rob wrote: >> >>>On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote: >> >>>>On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote: >> >>>>>There are no asynchronous inputs. All the inputs are sync'd to the >>>>>incoming slow 6kHz clock. The other fast internal FPGA MHz clock is >>>>>for something completely unrelated and has nothing to do with the SM. >> >>>>>Rob- Hide quoted text - >> >>>>Maybe add a free running counter that is clocked by the 6kHz clock >>>>that counts from 0 to 24 and then goes back to 0 resetting it only >>>>during powerup. Bring the counter out to debug pins. If your >>>>original hypothesis is correct that "...there is a spurious edge which >>>>my SM reacts to, thus causing erroneous data to be latched." then this >>>>counter would at some point end up at a non-zero count between >>>>transmissions (I'm assuming here that the transmissions are not >>>>continuous and there are identifiable gaps in time during which the >>>>state machine is waiting for the next 25 clock transmission to >>>>occur). With that setup you can also look for times when the counter >>>>changes states quicker than the expected 6 kHz rate. It can be a tad >>>>difficult depending on what equipment you can bring to bear and how >>>>many debug pins you have in your FPGA, but at least it gives you a >>>>direct view of flops inside the device that are being clocked and that >>>>will change state with every clock. >> >>>I already have a counter (that counts from 0 to 24) tied to the >>>incoming 6kHz clock. It is this counter that determines where I am in >>>the serial stream; and thus determines which flop within my data >>>register gets clocked with the incoming data. But yes, I have already >>>thought about doing this. But I don't need to--read below. >> >>>>Building somewhat further on that approach, if the state machine >>>>already has a signal that identifies the 'waiting for a new >>>>transmission to occur' time, then you could gate that signal with the >>>>counter being 0 and simply output a '1' when the protocol has been >>>>broken. That gives you one specific signal to monitor to trigger the >>>>scope. >> >>>>Either of those approaches though is only meant to give you a known >>>>reliable trigger mechanism for a scope or logic analyzer so you can >>>>investigate further (if it triggers) or reject your hypothesis (if it >>>>does not). >> >>>>It's also not really clear whether you have such a trigger condition >>>>or if you're relying on perhaps some higher level system observation >>>>instead. Your original thought to build a pulse monitor was somewhat >>>>along these lines, the problem with that approach though is that >>>>you're jumping to a solution that has holes to it. Even if your >>>>hypothesis is correct you haven't actually verified the root cause >>>>problem. >> >>>I did build the pulse monitor and the problem got worse. This of >>>course told me that I must be fighting a timing that is on the hairy >>>edge, as there is a slight delay through my "filter". So I started >>>looking at the path in much more scrutiny and found a section of the >>>placement that didn't have a lot of margin. I tightened this up and >>>the problems have disappeared. This obviously makes more sense since >>>I never saw any glitches/runts on the scope. And it also explains why >>>some boards worked and some didn't. >> >>>Again, I appreciate the dialogue.... >> >>If this is an issue of the relative timing of the clock and data >>as you note above, why not just take the data on the other edge >>of the clock where it is stable and there are no timing issues >>at all? > > > The master sends out the data on the falling edge so one would think > that since I'm using the rising edge of the clock that there would be > plenty of tsu time. Are you feeding the clock signal into the fpga on a clock pin or a data pin? Any signals that go around on nonclock nets and get used for clocks at some point are going to be trouble because the skew will make shift registers very unpredictable. What you are describing sounds like that since you are taking the data on the "good" side of the clock. You could also use your internal clock to make a latch and filter on the clock line and the rising edge detection after the filter could enable a shift.Article: 136884
I'm sorry. I didn't know I couldn't offer jobs here. Besides that, the person who's interested would sign a contract and receive the hardware needed by mail to work at home. That's why I didn't say where.Article: 136885
On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL) using Xilinx 10.1 EDK. If I attempt to specify the address bus as 17 bits in the MHS file I'll get the following error when generating the bitstream: ----------------------------------------------------------- ERROR:MDT - GLOBAL PORT:fpga_0_SRAM_A_pin CONNECTOR:fpga_0_SRAM_A - C:\Xilinx\Projects\dlp-fpga_project_5\system.mhs line 21 - 32 bit- width connector assigned to 17 bit-width port Completion time: 0.00 seconds ERROR:MDT - platgen failed with errors! ----------------------------------------------------------- If I specify the address bus width of the fpga_0_SRAM_A_pin vector to be 32 bits the project will complete without errors. However, I then have to specify IO definitions for address lines 17-31 in the UCF file. Is there some setting I can use in the MHS to get the Xilinx EDK to accept that my address bus to the SRAM is 17 bits rather than 31 bits? I can't seem to find a parameter for the xps_mch_emc block that lets me specify the width of the external address bus. The relevant portions of the MHS file are show below. Thanks! Mike Thompson ----------------------------------------------------------- ... PORT fpga_0_SRAM_DQ_pin = fpga_0_SRAM_DQ, DIR = IO, VEC = [7:0] PORT fpga_0_SRAM_A_pin = fpga_0_SRAM_A, DIR = O, VEC = [16:0] PORT fpga_0_SRAM_WEN_pin = fpga_0_SRAM_WEN, DIR = O PORT fpga_0_SRAM_OEN_pin = fpga_0_SRAM_OEN, DIR = O, VEC = [0:0] ... BEGIN xps_mch_emc PARAMETER INSTANCE = SRAM PARAMETER HW_VER = 2.00.a PARAMETER C_MAX_MEM_WIDTH = 8 PARAMETER C_MEM0_WIDTH = 8 PARAMETER C_SYNCH_MEM_0 = 0 PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 20000 PARAMETER C_NUM_BANKS_MEM = 1 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1 PARAMETER C_TCEDV_PS_MEM_0 = 70000 PARAMETER C_TWC_PS_MEM_0 = 50000 PARAMETER C_TAVDV_PS_MEM_0 = 70000 PARAMETER C_TWP_PS_MEM_0 = 50000 PARAMETER C_THZCE_PS_MEM_0 = 25000 PARAMETER C_TLZWE_PS_MEM_0 = 0 PARAMETER C_THZOE_PS_MEM_0 = 35000 PARAMETER C_XCL0_WRITEXFER = 0 PARAMETER C_MCH1_ACCESSBUF_DEPTH = 8 PARAMETER C_MEM0_BASEADDR = 0x81420000 PARAMETER C_MEM0_HIGHADDR = 0x8143ffff BUS_INTERFACE SPLB = mb_plb BUS_INTERFACE MCH0 = ixcl BUS_INTERFACE MCH1 = dxcl PORT Mem_A = fpga_0_SRAM_A PORT Mem_DQ = fpga_0_SRAM_DQ PORT Mem_WEN = fpga_0_SRAM_WEN PORT Mem_OEN = fpga_0_SRAM_OEN PORT RdClk = sys_clk_s END -----------------------------------------------------------Article: 136886
doug wrote: > > > Rob wrote: >> On Dec 10, 2:13 pm, doug <x...@xx.com> wrote: >> >>> Rob wrote: >>> >>>> On Dec 10, 12:14 pm, KJ <kkjenni...@sbcglobal.net> wrote: >>> >>>>> On Dec 10, 11:43 am, Rob <robns...@frontiernet.net> wrote: >>> >>>>>> There are no asynchronous inputs. All the inputs are sync'd to the >>>>>> incoming slow 6kHz clock. The other fast internal FPGA MHz clock is >>>>>> for something completely unrelated and has nothing to do with the SM. >>> >>>>>> Rob- Hide quoted text - >>> >>>>> Maybe add a free running counter that is clocked by the 6kHz clock >>>>> that counts from 0 to 24 and then goes back to 0 resetting it only >>>>> during powerup. Bring the counter out to debug pins. If your >>>>> original hypothesis is correct that "...there is a spurious edge which >>>>> my SM reacts to, thus causing erroneous data to be latched." then this >>>>> counter would at some point end up at a non-zero count between >>>>> transmissions (I'm assuming here that the transmissions are not >>>>> continuous and there are identifiable gaps in time during which the >>>>> state machine is waiting for the next 25 clock transmission to >>>>> occur). With that setup you can also look for times when the counter >>>>> changes states quicker than the expected 6 kHz rate. It can be a tad >>>>> difficult depending on what equipment you can bring to bear and how >>>>> many debug pins you have in your FPGA, but at least it gives you a >>>>> direct view of flops inside the device that are being clocked and that >>>>> will change state with every clock. >>> >>>> I already have a counter (that counts from 0 to 24) tied to the >>>> incoming 6kHz clock. It is this counter that determines where I am in >>>> the serial stream; and thus determines which flop within my data >>>> register gets clocked with the incoming data. But yes, I have already >>>> thought about doing this. But I don't need to--read below. >>> >>>>> Building somewhat further on that approach, if the state machine >>>>> already has a signal that identifies the 'waiting for a new >>>>> transmission to occur' time, then you could gate that signal with the >>>>> counter being 0 and simply output a '1' when the protocol has been >>>>> broken. That gives you one specific signal to monitor to trigger the >>>>> scope. >>> >>>>> Either of those approaches though is only meant to give you a known >>>>> reliable trigger mechanism for a scope or logic analyzer so you can >>>>> investigate further (if it triggers) or reject your hypothesis (if it >>>>> does not). >>> >>>>> It's also not really clear whether you have such a trigger condition >>>>> or if you're relying on perhaps some higher level system observation >>>>> instead. Your original thought to build a pulse monitor was somewhat >>>>> along these lines, the problem with that approach though is that >>>>> you're jumping to a solution that has holes to it. Even if your >>>>> hypothesis is correct you haven't actually verified the root cause >>>>> problem. >>> >>>> I did build the pulse monitor and the problem got worse. This of >>>> course told me that I must be fighting a timing that is on the hairy >>>> edge, as there is a slight delay through my "filter". So I started >>>> looking at the path in much more scrutiny and found a section of the >>>> placement that didn't have a lot of margin. I tightened this up and >>>> the problems have disappeared. This obviously makes more sense since >>>> I never saw any glitches/runts on the scope. And it also explains why >>>> some boards worked and some didn't. >>> >>>> Again, I appreciate the dialogue.... >>> >>> If this is an issue of the relative timing of the clock and data >>> as you note above, why not just take the data on the other edge >>> of the clock where it is stable and there are no timing issues >>> at all? >> >> >> The master sends out the data on the falling edge so one would think >> that since I'm using the rising edge of the clock that there would be >> plenty of tsu time. > > Are you feeding the clock signal into the fpga on a clock pin or > a data pin? Any signals that go around on nonclock nets and > get used for clocks at some point are going to be trouble because > the skew will make shift registers very unpredictable. What you > are describing sounds like that since you are taking the data > on the "good" side of the clock. You could also use your internal > clock to make a latch and filter on the clock line and the rising edge > detection after the filter could enable a shift. The clock is on a clock pin and feeds the global clock network.Article: 136887
Hi everyone, I am a masters student at, studying a pipelined FPGA model. What I want to do is convert a Verilog HDL file to a custom FPGA architecture eg, to a FPGA with 3 input LUTS and no carry support etc, a very basic architecture. Is there any way to specify my own part, so that a mapper will map to a 3-lut instead? (i was using quatrus_map, but I can't get it to map to a custom architecture) I also tried using VPR/ODIN, but had some problems. Also I feel maybes its overkill? Basically I just want to use a verilog hdl mapper but I want to change the architecture its mapping to. Is there any kind of open standard I can use to specify my FPGA architecture? (ie the lut suze, flip flops, fanout, fpga size, etc) Any help pointing me in the right direction would be a great help, Im a little bit confused at where to start. ThanksArticle: 136888
Hi! I think that the MPMC documentation is a good starting point here (part of the EDK). All the signals of the NPI interface are explained here. Furthermore, timing diagrams show how using it should look like. I was able to use the interface with this documentation. In Genode we use the NPI interface to read pixel data from the memory or to clear a memory region by bursts rather than by software. The code there is not so easy to understand though, since there is quite a lot of overhead for the framebuffer controlling (fpga-graphics.org). Another VGA controller using the NPI is available on opencores.org. Matthias google@schwarzers.de schrieb: > Hello all, > > as a newbe with FPGAs I have no clue how to use the NPI interface of > the MPMC from Xilinx. > I haven't found a really good example. > What I need is a simple module in VHDL which reads and writes the > memory (maybe a simple memory test). > > Is there something available ??? Can someone help me out ? > > Thanks a lot! > > /HBArticle: 136889
On 2008-12-11, Brian Drummond <brian_drummond@btconnect.com> wrote: > One option would be to translate a post-synthesis netlist (e.g. from > Quartus or Xilinx Webpack) which has already been translated into a > finite set of primitives; 4-LUTs, carry structures and the like. You should probably read the EULA thoroughly before doing this though. I believe that all major FPGA vendors have some language in the EULA which tries to prohibit you from doing this. Perhaps you could download the source code to Icarus and see how hard it would be to add synthesis support for your FPGA architecture instead? /AndreasArticle: 136890
On Dec 11, 3:26 am, mpthompson <mpthomp...@gmail.com> wrote: > On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC > memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL) > using Xilinx 10.1 EDK. If I attempt to specify the address bus as 17 > bits in the MHS file I'll get the following error when generating the > bitstream: > > ----------------------------------------------------------- > ERROR:MDT - GLOBAL PORT:fpga_0_SRAM_A_pin CONNECTOR:fpga_0_SRAM_A - > C:\Xilinx\Projects\dlp-fpga_project_5\system.mhs line 21 - 32 bit- > width > connector assigned to 17 bit-width port > Completion time: 0.00 seconds > ERROR:MDT - platgen failed with errors! > ----------------------------------------------------------- > > If I specify the address bus width of the fpga_0_SRAM_A_pin vector to > be 32 bits the project will complete without errors. However, I then > have to specify IO definitions for address lines 17-31 in the UCF > file. > > Is there some setting I can use in the MHS to get the Xilinx EDK to > accept that my address bus to the SRAM is 17 bits rather than 31 > bits? I can't seem to find a parameter for the xps_mch_emc block that > lets me specify the width of the external address bus. > > The relevant portions of the MHS file are show below. > > Thanks! > > Mike Thompson > > ----------------------------------------------------------- > ... > > PORT fpga_0_SRAM_DQ_pin = fpga_0_SRAM_DQ, DIR = IO, VEC = [7:0] > PORT fpga_0_SRAM_A_pin = fpga_0_SRAM_A, DIR = O, VEC = [16:0] > PORT fpga_0_SRAM_WEN_pin = fpga_0_SRAM_WEN, DIR = O > PORT fpga_0_SRAM_OEN_pin = fpga_0_SRAM_OEN, DIR = O, VEC = [0:0] > ... > > BEGIN xps_mch_emc > PARAMETER INSTANCE = SRAM > PARAMETER HW_VER = 2.00.a > PARAMETER C_MAX_MEM_WIDTH = 8 > PARAMETER C_MEM0_WIDTH = 8 > PARAMETER C_SYNCH_MEM_0 = 0 > PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 20000 > PARAMETER C_NUM_BANKS_MEM = 1 > PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1 > PARAMETER C_TCEDV_PS_MEM_0 = 70000 > PARAMETER C_TWC_PS_MEM_0 = 50000 > PARAMETER C_TAVDV_PS_MEM_0 = 70000 > PARAMETER C_TWP_PS_MEM_0 = 50000 > PARAMETER C_THZCE_PS_MEM_0 = 25000 > PARAMETER C_TLZWE_PS_MEM_0 = 0 > PARAMETER C_THZOE_PS_MEM_0 = 35000 > PARAMETER C_XCL0_WRITEXFER = 0 > PARAMETER C_MCH1_ACCESSBUF_DEPTH = 8 > PARAMETER C_MEM0_BASEADDR = 0x81420000 > PARAMETER C_MEM0_HIGHADDR = 0x8143ffff > BUS_INTERFACE SPLB = mb_plb > BUS_INTERFACE MCH0 = ixcl > BUS_INTERFACE MCH1 = dxcl > PORT Mem_A = fpga_0_SRAM_A > PORT Mem_DQ = fpga_0_SRAM_DQ > PORT Mem_WEN = fpga_0_SRAM_WEN > PORT Mem_OEN = fpga_0_SRAM_OEN > PORT RdClk = sys_clk_s > END > ----------------------------------------------------------- You are obviously trying to connect 17bit Address pins to 32bit port defined in your xps_mch_emc. You shold properly adjust Address (A) bus width in your peripheral. Take a look at S3E Starter Kit reference design or build one with a BSB. Cheers, AlesArticle: 136891
On Dec 11, 3:26 am, mpthompson <mpthomp...@gmail.com> wrote: > On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC > memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL) > using Xilinx 10.1 EDK. If I attempt to specify the address bus as 17 > bits in the MHS file I'll get the following error when generating the > bitstream: > > ----------------------------------------------------------- > ERROR:MDT - GLOBAL PORT:fpga_0_SRAM_A_pin CONNECTOR:fpga_0_SRAM_A - > C:\Xilinx\Projects\dlp-fpga_project_5\system.mhs line 21 - 32 bit- > width > connector assigned to 17 bit-width port > Completion time: 0.00 seconds > ERROR:MDT - platgen failed with errors! > ----------------------------------------------------------- > > If I specify the address bus width of the fpga_0_SRAM_A_pin vector to > be 32 bits the project will complete without errors. However, I then > have to specify IO definitions for address lines 17-31 in the UCF > file. > > Is there some setting I can use in the MHS to get the Xilinx EDK to > accept that my address bus to the SRAM is 17 bits rather than 31 > bits? I can't seem to find a parameter for the xps_mch_emc block that > lets me specify the width of the external address bus. > > The relevant portions of the MHS file are show below. > > Thanks! > > Mike Thompson > > ----------------------------------------------------------- > ... > > PORT fpga_0_SRAM_DQ_pin = fpga_0_SRAM_DQ, DIR = IO, VEC = [7:0] > PORT fpga_0_SRAM_A_pin = fpga_0_SRAM_A, DIR = O, VEC = [16:0] > PORT fpga_0_SRAM_WEN_pin = fpga_0_SRAM_WEN, DIR = O > PORT fpga_0_SRAM_OEN_pin = fpga_0_SRAM_OEN, DIR = O, VEC = [0:0] > ... > > BEGIN xps_mch_emc > PARAMETER INSTANCE = SRAM > PARAMETER HW_VER = 2.00.a > PARAMETER C_MAX_MEM_WIDTH = 8 > PARAMETER C_MEM0_WIDTH = 8 > PARAMETER C_SYNCH_MEM_0 = 0 > PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 20000 > PARAMETER C_NUM_BANKS_MEM = 1 > PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1 > PARAMETER C_TCEDV_PS_MEM_0 = 70000 > PARAMETER C_TWC_PS_MEM_0 = 50000 > PARAMETER C_TAVDV_PS_MEM_0 = 70000 > PARAMETER C_TWP_PS_MEM_0 = 50000 > PARAMETER C_THZCE_PS_MEM_0 = 25000 > PARAMETER C_TLZWE_PS_MEM_0 = 0 > PARAMETER C_THZOE_PS_MEM_0 = 35000 > PARAMETER C_XCL0_WRITEXFER = 0 > PARAMETER C_MCH1_ACCESSBUF_DEPTH = 8 > PARAMETER C_MEM0_BASEADDR = 0x81420000 > PARAMETER C_MEM0_HIGHADDR = 0x8143ffff > BUS_INTERFACE SPLB = mb_plb > BUS_INTERFACE MCH0 = ixcl > BUS_INTERFACE MCH1 = dxcl > PORT Mem_A = fpga_0_SRAM_A > PORT Mem_DQ = fpga_0_SRAM_DQ > PORT Mem_WEN = fpga_0_SRAM_WEN > PORT Mem_OEN = fpga_0_SRAM_OEN > PORT RdClk = sys_clk_s > END > ----------------------------------------------------------- One more thing. Usually the bus is splitted with "util_bus_split" core.Article: 136892
When reading for example the Virtex 4 datasheet under switching characteristics. More specifically the section named "Clock Buffers and Networks", there is a value F_MAX which is specified as the maximum frequency for a global clock tree. This value is 500 MHz in a Virtex-4 speedgrade 12. However, when synthesizing simple designs which are heavily pipelined it is easy to get a design which the static timing analysis tool reports as having a maximum frequency of significantly higher than 500 MHz in a speedgrade 12 device. There is no warning in the trce output about exceeding F_MAX. Since I have bitten in the past by the static timing analyser [1] I thought it best to ask here whether trce is right in ignoring F_MAX or not. (I tried to ask this on the message board on Xilinx' website but never got a satisfactory answer.) /Andreas [1] http://www.google.com/url?q=http://groups.google.com/g/3f77ff01/t/b9de1a095ac08f5a/d/54a6b4955bca044d%3Fie%3Dutf-8%26oe%3Dutf-8%26q%3Dcontradicting%2Bmessages%2Behliar%2354a6b4955bca044d&usg=AFQjCNFW8HKRjzEDkVdYxGbCJQgKIN5MoQArticle: 136893
On Wed, 10 Dec 2008 18:26:37 -0800 (PST), mpthompson <mpthompson@gmail.com> wrote: >On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC >memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL) >using Xilinx 10.1 EDK. > >If I specify the address bus width of the fpga_0_SRAM_A_pin vector to >be 32 bits the project will complete without errors. However, I then >have to specify IO definitions for address lines 17-31 in the UCF >file. In EDK 7.1 there used to be an IP core you could instantiate, simply to extract a slice out of a longer word. Maybe it's still there? (Sorry, I can't remember its name but it should be easy to find) It seemed like a sledgehammer to crack a nut, but it kept the design within the EDK [paradigm|straitjacket], and I think it will do what you want. Instead I just used my EDK project as a component within an ISE project, so I was free to do anything I wanted outside it. - BrianArticle: 136894
On Wed, 10 Dec 2008 21:32:04 -0800 (PST), Ben D <bsdevlin@gmail.com> wrote: >Hi everyone, > >I am a masters student at, studying a pipelined FPGA model. What I >want to do is convert a Verilog HDL file to a custom FPGA architecture >eg, to a FPGA with 3 input LUTS and no carry support etc, a very basic >architecture. > >Is there any way to specify my own part, so that a mapper will map to >a 3-lut instead? (i was using quatrus_map, but I can't get it to map >to a custom architecture) If you can't find a general solution... One option would be to translate a post-synthesis netlist (e.g. from Quartus or Xilinx Webpack) which has already been translated into a finite set of primitives; 4-LUTs, carry structures and the like. You can reduce the set of primitives somewhat, either by targeting older, simpler FPGAs or by setting synthesis options to avoid special features (MUXF5,6 and MULT18). Then you only have to transform each of those primitives into your target technology (LUT being trivial when 3 or fewer inputs used!) and you have a solution of sorts ... locally sub-optimal (e.g. where you translated carry chain to LUTs) but easy to get correct. Local optimisations may be possible as a separate step. Extract a list of primitives from an example netlist to gauge the size of the problem. Scanning one such (Xilinx) netlist shows two "CY" primitives (MUXCY,XORCY), many LUT2 and INV and FD components (and a MULT18, ahem!) forming the vast majority of them. - BrianArticle: 136895
Does someone has a mini EDK project with sources for me ? I would really appreciate it ... :-)Article: 136896
The pulse will be twice or half as long as normal depending on whether you get an extra trigger on the rising or falling edge. You can just trigger on the rising edge and look at the output a couple of clocks later. It should be a clock, but if you get an eye diagram then you got an extra clock on the the clock and if your clock shifts by 90 degrees then you got a rising edge during the falling edge. ColinArticle: 136897
On Dec 10, 1:05=A0pm, Rob <robns...@frontiernet.net> wrote: > > I did build the pulse monitor and the problem got worse. =A0This of > course told me that I must be fighting a timing that is on the hairy > edge, as there is a slight delay through my "filter". =A0So I started > looking at the path in much more scrutiny and found a section of the > placement that didn't have a lot of margin. =A0I tightened this up and > the problems have disappeared. =A0This obviously makes more sense since > I never saw any glitches/runts on the scope. =A0And it also explains why > some boards worked and some didn't. > A "path that didn't have a lot of margin" where you "tightened this up and the problems have disappeared" on a design that that is running at 6 kHz in an FPGA where the 6 kHz clock is coming in on a clock pin and the inputs change on the opposite edge of the receiving clock is somewhat nonsensical. Presumably the path you've run across is in fact a clock domain transfer between the 6 kHz and the FPGA's main clock. Assuming that, if you insist on using the 6 kHz input as a clock input to a register then the only way to correct the design 100% is - Proper handshaking across the interface - A dual clock fifo would (but this would likely be overkill here) If your fix did not change the source code logic description to implement one of the above two methods, but instead only involved adding or manipulating fitter timing/placement/whatever constraints then you haven't really fixed the problem, it will come back to bite you with near 100% certainty. Based on your description, it appears the FPGA implements a SPI slave external interface that is controlled by some external processor. Presumably the processor needs to setup control registers and read back status from the FPGA for the system to work. At some point in such a system there will have to be a clock domain crossing. Since there is probably a large difference between the main FPGA clock frequency and the SPI clock frequency of 6 kHz, a much more robust and simpler approach then the two listed above would have been to simply synchronize the SPI bus inputs (including clock) to the FPGA clock as one would do with any other asynchronous input. Then look for the SPI clock transitions within the FPGA clock domain, the SPI clock input signal would not be used as a clock input to any registers. That way there is only one clock domain, not two so there is no clock domain crossing issue. Whenever you have a large frequency difference between two 'clocks' and the setup/hold times are rather relaxed this approach should always be the first solution to persue. Kevin JenningsArticle: 136898
Just a polling question, which way people use the most to insert the Chipscope into the design? For my own, if using the Inserter to add Chipscope to the ngc netlist, then there're chances the Tranlate step has changed your net names around make it difficult to see and attach what you have built and want to attach to the scope ThnksArticle: 136899
Avnet has an example using a 1Mx8 Cypress MicroPower SRAM with Spartan-3A MicroBlaze (EDK 10.1.3). You can find it at www.em.avnet.com/mx= p-sram --> Support Files & Downloads. The example was generated using BSB, which automatically instantiates IP UTIL_BUS_SPLIT to align the busses. Bryan PORT fpga_0_SRAM_1Mx8_Mem_A_pin =3D fpga_0_SRAM_1Mx8_Mem_A, DIR =3D O, VEC =3D [12:31] PORT fpga_0_SRAM_1Mx8_Mem_DQ_pin =3D fpga_0_SRAM_1Mx8_Mem_DQ, DIR =3D IO, VEC =3D [0:7] PORT fpga_0_SRAM_1Mx8_Mem_OEN_pin =3D fpga_0_SRAM_1Mx8_Mem_OEN, DIR =3D O, VEC =3D [0:0] PORT fpga_0_SRAM_1Mx8_Mem_CEN_pin =3D fpga_0_SRAM_1Mx8_Mem_CEN, DIR =3D O, VEC =3D [0:0] PORT fpga_0_SRAM_1Mx8_Mem_WEN_pin =3D fpga_0_SRAM_1Mx8_Mem_WEN, DIR =3D O PORT fpga_0_SRAM_1Mx8_Mem_CE_pin =3D fpga_0_SRAM_1Mx8_Mem_CE, DIR =3D O, VEC =3D [0:0] BEGIN xps_mch_emc PARAMETER INSTANCE =3D SRAM_1Mx8 PARAMETER HW_VER =3D 2.00.a PARAMETER C_MCH_PLB_CLK_PERIOD_PS =3D 20833 PARAMETER C_NUM_BANKS_MEM =3D 1 PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 =3D 1 PARAMETER C_SYNCH_MEM_0 =3D 0 PARAMETER C_MEM0_WIDTH =3D 8 PARAMETER C_MAX_MEM_WIDTH =3D 8 PARAMETER C_TCEDV_PS_MEM_0 =3D 45000 PARAMETER C_TWC_PS_MEM_0 =3D 35000 PARAMETER C_TAVDV_PS_MEM_0 =3D 45000 PARAMETER C_TWP_PS_MEM_0 =3D 35000 PARAMETER C_THZCE_PS_MEM_0 =3D 0 PARAMETER C_TLZWE_PS_MEM_0 =3D 0 PARAMETER C_MCH0_ACCESSBUF_DEPTH =3D 4 PARAMETER C_XCL0_WRITEXFER =3D 0 PARAMETER C_MCH1_ACCESSBUF_DEPTH =3D 8 PARAMETER C_MEM0_BASEADDR =3D 0x84900000 PARAMETER C_MEM0_HIGHADDR =3D 0x849fffff BUS_INTERFACE SPLB =3D mb_plb BUS_INTERFACE MCH0 =3D ixcl BUS_INTERFACE MCH1 =3D dxcl PORT Mem_A =3D fpga_0_SRAM_1Mx8_Mem_A_split PORT Mem_DQ =3D fpga_0_SRAM_1Mx8_Mem_DQ PORT Mem_OEN =3D fpga_0_SRAM_1Mx8_Mem_OEN PORT Mem_CEN =3D fpga_0_SRAM_1Mx8_Mem_CEN PORT Mem_WEN =3D fpga_0_SRAM_1Mx8_Mem_WEN PORT Mem_CE =3D fpga_0_SRAM_1Mx8_Mem_CE PORT RdClk =3D sys_clk_s END BEGIN util_bus_split PARAMETER INSTANCE =3D SRAM_1Mx8_util_bus_split_1 PARAMETER HW_VER =3D 1.00.a PARAMETER C_SIZE_IN =3D 32 PARAMETER C_LEFT_POS =3D 0 PARAMETER C_SPLIT =3D 12 PORT Sig =3D fpga_0_SRAM_1Mx8_Mem_A_split PORT Out2 =3D fpga_0_SRAM_1Mx8_Mem_A END On Dec 11, 6:12=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 10 Dec 2008 18:26:37 -0800 (PST), mpthompson > > <mpthomp...@gmail.com> wrote: > >On a Xilinx Spartan 3e FPGA, I'm attempting to use the XPS MCH EMC > >memory controller to connect with an 128Kx8 SRAM chip (CY62128DV30LL) > >using Xilinx 10.1 EDK. =A0 > > >If I specify the address bus width of the fpga_0_SRAM_A_pin vector to > >be 32 bits the project will complete without errors. =A0However, I then > >have to specify IO definitions for address lines 17-31 in the UCF > >file. > > In EDK 7.1 there used to be an IP core you could instantiate, simply to > extract a slice out of a longer word. Maybe it's still there? (Sorry, I > can't remember its name but it should be easy to find) > > It seemed like a sledgehammer to crack a nut, but it kept the design > within the EDK [paradigm|straitjacket], and I think it will do what you > want. > > Instead I just used my EDK project as a component within an ISE project, > so I was free to do anything I wanted outside it. > > - Brian
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