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've been trying to work with an SDRAM chip. I see that I need to refresh every 64 ms. I can do this using Auto Refresh. Supposedly, Auto Refresh uses an internal counter to count the row addresses so I don't have to use an external one. However, I still need to use a counter to count how many Auto Refresh commands I need to give, which, quite logically, is the number of rows! So are we just duplicating a counter here? What am I missing?Article: 147951
On Thu, 3 Jun 2010 13:19:18 -0700 (PDT), Vivek Menon <vivek.menon79@gmail.com> wrote: >Alan: > >Thanks for these tips. >> 2. Look for being off by an output stride permutation or transpose. >I am not sure how to check this. Can you elaborate ? You started quite well, in your previous post. You observed: > xk_re[0] 117467 Matlab:f2_r[0] 117467 and > But on closer observation, the 64th value obtained from Xilinx > simulation is same as the 2nd value, i.e. > xk_re[64] 6002.34 = Matlab:f2_r[1] 6002.34 Just take this further. Compare xk_re[128] with Matlab:f2_r[2] xk_re[192] with Matlab:f2_r[3] xk_re[256] with Matlab:f2_r[4] and so on. A pattern might become visible. The solution may turn out to be as simple as re-ordering address bits in one output array to match the other. - BrianArticle: 147952
Giorgos Tzampanakis <gt67@hw.ac.uk> wrote in news:Xns9D8CF3586BF9Dfdnbgui7uhu5h8hrnuio@81.169.183.62: > I've been trying to work with an SDRAM chip. I see that I need to > refresh every 64 ms. I can do this using Auto Refresh. > > Supposedly, Auto Refresh uses an internal counter to count the > row addresses so I don't have to use an external one. However, I > still need to use a counter to count how many Auto Refresh > commands I need to give, which, quite logically, is the number of > rows! > > So are we just duplicating a counter here? What am I missing? > If there are N rows, don't you just refresh every 64/N ms (or a little less for margin) ? You may need a counter to get the timing, but you don't need a counter for counting rows. I admit to being puzzled about how you get started, unless you wait 64 ms before making first use of the SDRAM.Article: 147953
On Thu, 3 Jun 2010 22:55:18 +0000 (UTC), Giorgos Tzampanakis <gt67@hw.ac.uk> wrote: >I've been trying to work with an SDRAM chip. I see that I need to >refresh every 64 ms. I can do this using Auto Refresh. > >Supposedly, Auto Refresh uses an internal counter to count the >row addresses so I don't have to use an external one. However, I >still need to use a counter to count how many Auto Refresh >commands I need to give, which, quite logically, is the number of >rows! > >So are we just duplicating a counter here? What am I missing? It's normal to not generate all the refresh pulses at once. So if your datasheet informs you that there are 8192 rows to refresh, you generate 1 refresh pulse every 64ms/8192, or every 7.8 us approx, instead of 8192 at once. In any case a refresh pulse places a huge demand on the PSU, so a burst of 8192 at once may cause PSU troubles or thermal problems in the DRAM. Check the datasheet for restrictions on the interval between refresh pulses. Newer technologies (DDR,DDR2 etc) are quite restricted in the interval between refresh pulses. They typically require at least one every 70 us (not ms) which effectively means you can defer up to 8 refresh pulses and burst them after 70us, but data integrity is not guaranteed if you get further behind than that. It is probably 10 years since I looked at a SDRAM datasheet, but it is quite likely they have a similar restriction. - BrianArticle: 147954
On Jun 4, 10:08=A0am, rickman <gnu...@gmail.com> wrote: > Assuming you *need* the OS level portion. =A0If I understand the XMOS > device, they have pipelined their design, but instead of trying to use > that to speed up a single processor, they treat it as a time sliced > multi-processor. =A0Zero overhead other than the muxing of the multiple > registers. =A0The trade off is that each of the N processors run as if > they are not pipelined at 1/N of the clock rate. =A0I guess there may be > some complexity in the interrupt controller too. =A0So for the cost of 1 > processor in terms of logic, they get N processors running > concurrently. Close, they can run up to 4 threads, with no speed impact, but really that's because they limit to no more than C/4. Above 4, and that C/N starts to show, What XMOS forgot to do, was allow good HW capture on the pins. Perhaps, being SW centric, they figured all problems can be solved with code, but that always has a time ceiling. > =A0I may take a look at doing that in my processor. =A0The > code space could even be shared. While you have the hood open, also look at making the Interrupt response times always the same ?. (The new M0 claims to do this) Often jitter is a far worse problem than absolute delays. -jgArticle: 147955
On Jun 3, 7:40=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 3 Jun 2010 22:55:18 +0000 (UTC), Giorgos Tzampanakis > > <g...@hw.ac.uk> wrote: > >I've been trying to work with an SDRAM chip. I see that I need to > >refresh every 64 ms. I can do this using Auto Refresh. > > >Supposedly, Auto Refresh uses an internal counter to count the > >row addresses so I don't have to use an external one. However, I > >still need to use a counter to count how many Auto Refresh > >commands I need to give, which, quite logically, is the number of > >rows! > > >So are we just duplicating a counter here? What am I missing? > > It's normal to not generate all the refresh pulses at once. So if your > datasheet informs you that there are 8192 rows to refresh, you generate > 1 refresh pulse every 64ms/8192, or every 7.8 us approx, instead of 8192 > at once. > > In any case a refresh pulse places a huge demand on the PSU, so a burst > of 8192 at once may cause PSU troubles or thermal problems in the DRAM. > Check the datasheet for restrictions on the interval between refresh > pulses. > > Newer technologies (DDR,DDR2 etc) are quite restricted in the interval > between refresh pulses. They typically require at least one every 70 us > (not ms) which effectively means you can defer up to 8 refresh pulses > and burst them after 70us, but data integrity is not guaranteed if you > get further behind than that. > > It is probably 10 years since I looked at a SDRAM datasheet, but it is > quite likely they have a similar restriction. > > - Brian The single datarate parts don't have any timing restrictions on refresh other than meeting the 64 ms between refresh to any row. In fact under some circumstances, like video frame buffers where all rows are accessed anyway, you don't need to do auto-refresh at all. DDR parts are a different beast altogether. They contain delay locked loops and the JEDEC spec recommends refresh every 15 microseconds because the refresh time is used to update the loop lock. Individual manufacturers, including Micron have less stringent requirements, but it can't hurt to design for the JEDEC case. Anyway if you just figure out the rate and spread out the refreshes you don't need the row counter. You still need some sort of counter to time the refresh interval, though. Regards, GaborArticle: 147956
Brian: Thanks for that info. As per your suggestion, I tried looking for a pattern and I got xk_re[0] =3D 117020.000000 out1[0] =3D 117020.000000 xk_re[64] =3D 6299.545898 out1[1] =3D 6299.546058 xk_re[128] =3D -480.795319 out1[2] =3D -480.795307 xk_re[192] =3D -2098.480957 out1[3] =3D -2098.480978 xk_re[256] =3D 514.060181 out1[4] =3D 514.060169 xk_re[320] =3D 2333.583740 out1[5] =3D 2333.583723 xk_re[384] =3D -1662.341797 out1[6] =3D -1662.341746 xk_re[448] =3D 1138.460815 out1[7] =3D 1138.460846 xk_re[512] =3D 999.444275 out1[8] =3D 999.444264 xk_re[576] =3D 1011.767090 out1[9] =3D 1011.766937 xk_re[640] =3D 675.801819 out1[10] =3D 675.801815 xk_re[704] =3D -228.494156 out1[11] =3D -228.494118 xk_re[768] =3D 125.878403 out1[12] =3D 125.878388 xk_re[832] =3D 967.332825 out1[13] =3D 967.332667 xk_re[896] =3D 957.770752 out1[14] =3D 957.770744 xk_re[960] =3D 521.345032 out1[15] =3D 521.345267 xk_re[1024] =3D 517.000000 out1[16] =3D 517.000000 xk_re[1088] =3D 304.085236 out1[17] =3D 304.085171 xk_re[1152] =3D 8.210644 out1[18] =3D 8.210658 xk_re[1216] =3D 977.692871 out1[19] =3D 977.692783 xk_re[1280] =3D 939.376404 out1[20] =3D 939.376446 xk_re[1344] =3D 834.504822 out1[21] =3D 834.504807 xk_re[1408] =3D 509.039398 out1[22] =3D 509.039446 xk_re[1472] =3D 687.585693 out1[23] =3D 687.585502 xk_re[1536] =3D 214.555710 out1[24] =3D 214.555736 xk_re[1600] =3D 266.508942 out1[25] =3D 266.509008 xk_re[1664] =3D 35.114548 out1[26] =3D 35.114484 xk_re[1728] =3D 328.139496 out1[27] =3D 328.139565 xk_re[1792] =3D 460.684998 out1[28] =3D 460.684997 xk_re[1856] =3D 881.765320 out1[29] =3D 881.765423 xk_re[1920] =3D 741.199890 out1[30] =3D 741.199907 xk_re[1984] =3D -33.342484 out1[31] =3D -33.342660 xk_re[2048] =3D 494.000000 out1[32] =3D 494.000000 xk_re[2112] =3D -33.342667 out1[33] =3D -33.342660 xk_re[2176] =3D 741.199890 out1[34] =3D 741.199907 xk_re[2240] =3D 881.765503 out1[35] =3D 881.765423 xk_re[2304] =3D 460.684998 out1[36] =3D 460.684997 xk_re[2368] =3D 328.139587 out1[37] =3D 328.139565 xk_re[2432] =3D 35.114426 out1[38] =3D 35.114484 xk_re[2496] =3D 266.509064 out1[39] =3D 266.509008 xk_re[2560] =3D 214.555710 out1[40] =3D 214.555736 xk_re[2624] =3D 687.585388 out1[41] =3D 687.585502 xk_re[2688] =3D 509.039368 out1[42] =3D 509.039446 xk_re[2752] =3D 834.504761 out1[43] =3D 834.504807 xk_re[2816] =3D 939.376404 out1[44] =3D 939.376446 xk_re[2880] =3D 977.692810 out1[45] =3D 977.692783 xk_re[2944] =3D 8.210655 out1[46] =3D 8.210658 xk_re[3008] =3D 304.085205 out1[47] =3D 304.085171 xk_re[3072] =3D 517.000000 out1[48] =3D 517.000000 xk_re[3136] =3D 521.345215 out1[49] =3D 521.345267 xk_re[3200] =3D 957.770813 out1[50] =3D 957.770744 xk_re[3264] =3D 967.332397 out1[51] =3D 967.332667 xk_re[3328] =3D 125.878403 out1[52] =3D 125.878388 xk_re[3392] =3D -228.494202 out1[53] =3D -228.494118 xk_re[3456] =3D 675.801880 out1[54] =3D 675.801815 xk_re[3520] =3D 1011.766968 out1[55] =3D 1011.766937 xk_re[3584] =3D 999.444275 out1[56] =3D 999.444264 xk_re[3648] =3D 1138.461060 out1[57] =3D 1138.460846 xk_re[3712] =3D -1662.341797 out1[58] =3D -1662.341746 xk_re[3776] =3D 2333.583740 out1[59] =3D 2333.583723 xk_re[3840] =3D 514.060181 out1[60] =3D 514.060169 xk_re[3904] =3D -2098.481201 out1[61] =3D -2098.480978 xk_re[3968] =3D -480.795227 out1[62] =3D -480.795307 xk_re[4032] =3D 6299.545898 out1[63] =3D 6299.546058 But why did this happen?? I did setup the Xilinx FFT core as 4096 pt natural order output with 32 bit floating point. Now I need to reorder the data as per this logic, then do the complex multiplication and then take an IFFT. Now I am not sure if my IFFT values will match Matlab. On Jun 3, 7:26=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 3 Jun 2010 13:19:18 -0700 (PDT), Vivek Menon > > <vivek.meno...@gmail.com> wrote: > >Alan: > > >Thanks for these tips. > >> 2. Look for being off by an output stride permutation or transpose. > >I am not sure how to check this. Can you elaborate ? > > You started quite well, in your previous post. > > You observed: > > > =A0xk_re[0] 117467 Matlab:f2_r[0] 117467 > > and > > > But on closer observation, the 64th value obtained from Xilinx > > simulation is same as the 2nd value, i.e. > > xk_re[64] 6002.34 =3D Matlab:f2_r[1] 6002.34 > > Just take this further. Compare > xk_re[128] =A0 =A0 =A0with =A0 =A0Matlab:f2_r[2] > xk_re[192] =A0 =A0 =A0with =A0 =A0Matlab:f2_r[3] > xk_re[256] =A0 =A0 =A0with =A0 =A0Matlab:f2_r[4] > and so on. > > A pattern might become visible. > > The solution may turn out to be as simple as re-ordering address bits in > one output array to match the other. > > - BrianArticle: 147957
On Jun 3, 9:01 pm, -jg <jim.granvi...@gmail.com> wrote: > On Jun 4, 10:08 am, rickman <gnu...@gmail.com> wrote: > > > Assuming you *need* the OS level portion. If I understand the XMOS > > device, they have pipelined their design, but instead of trying to use > > that to speed up a single processor, they treat it as a time sliced > > multi-processor. Zero overhead other than the muxing of the multiple > > registers. The trade off is that each of the N processors run as if > > they are not pipelined at 1/N of the clock rate. I guess there may be > > some complexity in the interrupt controller too. So for the cost of 1 > > processor in terms of logic, they get N processors running > > concurrently. > > Close, they can run up to 4 threads, with no speed impact, but really > that's because they limit to no more than C/4. Above 4, and that C/N > starts to show, I don't follow. I thought a processor was 8 way interleaved. Why does it slow with more than 4 threads? I see there are only four "hardware locks", but I can't find any mention of what they are and what they do. Is that what you are saying limits it somehow? > What XMOS forgot to do, was allow good HW capture on the pins. > Perhaps, being SW centric, they figured all problems can be solved > with code, but that always has a time ceiling. > > > I may take a look at doing that in my processor. The > > code space could even be shared. > > While you have the hood open, also look at making the Interrupt > response times always the same ?. > (The new M0 claims to do this) > Often jitter is a far worse problem than absolute delays. My processor is highly optimized for real time work. Every instruction is 1 clock cycle and the interrupt latency is always the same, 1 clock cycle. As soon as the interrupt winds its way through the interrupt controller logic (less than a clock cycle if the signal is already synchronous to the CPU clock) the next clock cycle jams an interrupt in place of the current instruction, saves the current address and the current PSW and jumps to the interrupt location, all in one clock cycle. That is one advantage of having two stacks, you can save two things at once. The only short coming is that the stacks *are* your working register set, so they are still pointing just above the last operands of the interrupted code. If you want to save interrupt context between states, you either have to explicitly save the data in memory somewhere on exit and restore it on reentry (very slow) or you need to save and restore the data stack pointer, one word to be saved in memory. I haven't tried writing the code for this yet. I'll be interested to see how much work the CPU has to do to save and restore the data stack pointer. With a round robin scheduling of tasks to the time slices, letting the interrupt use an uncommitted slice would mean a variable delay of 1 to 8 clocks, but then they are system clocks, not instruction clocks. Or an interrupt could just take the next time slice no matter what. I would think the whole tasking/interrupt thing could get very complex if priorities are involved. It would be much simpler to just assign an interrupt to a time slice and let it be shared between the interrupt and a lower priority task. RickArticle: 147958
On Jun 4, 3:32=A0pm, rickman <gnu...@gmail.com> wrote: > > > =A0Close, they can run up to 4 threads, with no speed impact, but reall= y > > that's because they limit to no more than C/4. Above 4, and that C/N > > starts to show, > > I don't follow. =A0I thought a processor was 8 way interleaved. =A0Why > does it slow with more than 4 threads? =A0I see there are only four > "hardware locks", but I can't find any mention of what they are and > what they do. =A0Is that what you are saying limits it somehow? My understanding is they chose to allow only 100MHz cpu rates at 400Mhz clock (maybe some I/O limits), so the Max CPU thread speed is 100Mhz/10ns, but you CAN launch up to 4 of these, with no impact (and so use up all slack 400MHz clocks) - thereafter, adding another thread, has to lower the total average CPU speed, until you get to the 8 x 50MHz CPU's point. An alternative approach would have been to allow 8 time Slots, and then map each slot to a thread. (8 x 3 bit entries) If they had done that, then 2x100MHz + 4 x 50MHz thread rates would have been possible, and less interaction between thread loading. Then, those 50MHz threads could start/stop, with no rate-cross-effects, and hopefully some power saving. -jgArticle: 147959
On Jun 4, 5:52=A0am, -jg <jim.granvi...@gmail.com> wrote: > On Jun 4, 3:32=A0pm, rickman <gnu...@gmail.com> wrote: > > > > > > =A0Close, they can run up to 4 threads, with no speed impact, but rea= lly > > > that's because they limit to no more than C/4. Above 4, and that C/N > > > starts to show, > > > I don't follow. =A0I thought a processor was 8 way interleaved. =A0Why > > does it slow with more than 4 threads? =A0I see there are only four > > "hardware locks", but I can't find any mention of what they are and > > what they do. =A0Is that what you are saying limits it somehow? > > My understanding is they chose to allow only 100MHz cpu rates at > 400Mhz clock (maybe some I/O limits), so the Max CPU thread speed is > 100Mhz/10ns, but you CAN launch up to 4 of these, with no impact (and > so use up all slack 400MHz clocks) - thereafter, adding another > thread, has to lower the total average CPU speed, until you get to the > 8 x 50MHz CPU's point. > > An alternative approach would have been to allow 8 time Slots, and > then map each slot to a thread. (8 x 3 bit entries) > > =A0If they had done that, then 2x100MHz + 4 x 50MHz thread rates would > have been possible, and less interaction between thread loading. Then, > those 50MHz threads could start/stop, with no rate-cross-effects, and > hopefully some power saving. > > -jg I can't say I understand this. The scheme I was thinking about would have had 8 time slots, each at 1/8th the system clock rate. There would be no way to utilize more than 1/8th the system clock rate for a single thread because then it would be pipelined and would require special logic to manage the issues that creates. I guess the devil is in the details and I really don't know how they are doing this. RickArticle: 147960
On Jun 4, 9:55=A0am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> wrote: > On Tue, 25 May 2010, Philip Pemberton sent: > > |----------------------------------------------------------------------| > |"[..] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > |Can't say I've tried Lattice's FPGAs. I looked at them a few years ago| > |and basically discounted them because I couldn't get hold of them =A0 = =A0 | > |(although I could get a programming cable... for =A3595, [..] =A0 =A0 = =A0 =A0 =A0 | > |[..] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| > |[..]" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > |----------------------------------------------------------------------| > > Yikes. That has changed. The ones I buy are available from stock at Mouser and the programming cable is $150 US. In fact, the part I am using the the lowest cost FPGA I can find in a 100 TQFP. It is a flash based XP3C device. The software works as well as anyone's and it is getting the job done. Other than the fact that this footprint has no upward compatible path I have no complaints. RickArticle: 147961
On Thu, 3 Jun 2010 20:28:11 -0700 (PDT), Vivek Menon <vivek.menon79@gmail.com> wrote: >Brian: > >Thanks for that info. As per your suggestion, I tried looking for a >pattern and I got > >xk_re[0] = 117020.000000 out1[0] = 117020.000000 >xk_re[64] = 6299.545898 out1[1] = 6299.546058 >xk_re[128] = -480.795319 out1[2] = -480.795307 >xk_re[192] = -2098.480957 out1[3] = -2098.480978 >But why did this happen?? I did setup the Xilinx FFT core as 4096 pt >natural order output with 32 bit floating point. Now I need to reorder >the data as per this logic, then do the complex multiplication and >then take an IFFT. Now I am not sure if my IFFT values will match >Matlab. At this point I think the next step is to read some introductory material about FFTs, paying attention to how FFTs can be decomposed into simpler ones. That should help you understand what is going on. - BrianArticle: 147962
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1194096343-1275659762=:3625 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 25 May 2010, Philip Pemberton sent: |----------------------------------------------------------------------| |"[..] | | | |Can't say I've tried Lattice's FPGAs. I looked at them a few years ago| |and basically discounted them because I couldn't get hold of them | |(although I could get a programming cable... for =C2=A3595, [..] = | |[..] | | | |[..]" | |----------------------------------------------------------------------| Yikes. --8323328-1194096343-1275659762=:3625--Article: 147963
On Jun 4, 6:28=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 3 Jun 2010 20:28:11 -0700 (PDT), Vivek Menon
>
> <vivek.meno...@gmail.com> wrote:
> >Brian:
>
> >Thanks for that info. As per your suggestion, I tried looking for a
> >pattern and I got
>
> >xk_re[0] =3D 117020.000000 out1[0] =3D 117020.000000
> >xk_re[64] =3D 6299.545898 out1[1] =3D 6299.546058
> >xk_re[128] =3D -480.795319 out1[2] =3D -480.795307
> >xk_re[192] =3D -2098.480957 out1[3] =3D -2098.480978
> >But why did this happen?? I did setup the Xilinx FFT core as 4096 pt
> >natural order output with 32 bit floating point. Now I need to reorder
> >the data as per this logic, then do the complex multiplication and
> >then take an IFFT. Now I am not sure if my IFFT values will match
> >Matlab.
>
> At this point I think the next step is to read some introductory
> material about FFTs, paying attention to how FFTs can be decomposed
> into simpler ones. That should help you understand what is going on.
>
> - Brian
Brian: Good catch!
Vivek:
Not really sure about the cause for this without more data.
Looks like a "Radix4-reversal" or a 64x64 transpose.
Make sure
output_ordering =3D{bit_reversed_order | natural_order}
is set right and that xk_index is behaved properly.
Other than that, the Matlab model and how you read in the data should
be checked.
To find the reverse permutation, here is some Scilab code that you can
convert to Matlab.
Call it with something like:
P=3Dfip(xk_re, out1, 0.0001)
function [P] =3D fip(x,y,epsln)
////Approx Inverse perm
if (size(x) <> size(y)) then break; end
for i=3D1:size(x,'*')
P(i)=3Dfind((abs(x-y(i)))<=3Depsln);
end
endfunction
good luck!
alan
Article: 147964
Hello Friends
Our group has finished a project which has
different modules in it, executing different tasks. We need to call
this different modules of the project from a different main file. For
callling each module, I have set a single bit input port for each
module in the project so that when these input ports are set, the
modules start working.
According to my knowledge in verilog, we could call the entire project
or all the modules together by setting all the input ports. But what
we want is,calling different modules of the project at different times
or calling one module more than once and other modules only once.(I
hope you understand this).I have tried to set the input ports
sequentially but only the last call or the last call of the module is
onlly executed.All the before calls are not getting executed.
Here are my some modules in the project
module project:
case(state)
IDLE: begin
if(reset == 1) begin
-----
--------
-------
next_state = STATE0;
end
STATE0: begin
if(inititate_i == 1) begin
---------
---------
---------
next_state = STATE1;
end
else
next_state = IDLE;
end
endmodule
My main program from which I called my project is -
mainprogramme:
main project instance;
main project reset =1;
main project inititate_i = 1;
main project reset = 1;
endmainprogramme
In the above case, only my second call of the reset is being
executed(I have written code in my project which will retain my old
values of the register,so there is no worry of that may be the values
are getting overwriiten). There is a simple way of calling the
different modules in the main project by just using a counter and
running t he module as many times as i require. But we don't want
that, beacuse the number of times a single module is called is not
decided before.
Could any one please give me suggestions for solving this probelm.I
would be great ful for the help.
Please help me. I have been trying on this problem from many days but
with no success.
Article: 147965I use an internal memory Spartan 3an When I try to burn only the FPGA I can! Even when I try to burn the FPGA and the prom I get in the middle of the recording process failed! And the reason he failed is: "'1': Configuration data download to FPGA was not successful. DONE did not go high, please check your configuration setup and spi mode settings. PROGRESS_END - End Operation." Would love to get any help Thanks! --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147966
On Jun 7, 9:12=A0am, "izaak" <aaazrad@n_o_s_p_a_m.gmail.com> wrote: > I use an internal memory Spartan 3an > When I try to burn only the FPGA I can! > Even when I try to burn the FPGA and the prom > I get in the middle of the recording process failed! > And the reason he failed is: > "'1': Configuration data download to FPGA was not successful. DONE did no= t > go high, please check your configuration setup and spi mode settings. > PROGRESS_END - End Operation." > > Would love to get any help > Thanks! > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com Check the Configuration User Guide for your FPGA, I think there's just one common guide for the Spartan 3 families. Make sure your mode pins and "VS" pins are tied to the appropriate voltages for SPI internal configuration. The message you get seems to indicate that the SPI flash ws programmed, but the FPGA did not properly load from it. Regards, GaborArticle: 147967
On Jun 5, 12:31=A0am, sandeep <sssgsand...@gmail.com> wrote: > Hello Friends > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Our group has finished a p= roject which has > different modules in it, executing different tasks. We need to call > this different modules of the project from a different main file. For > callling each module, I have set a single bit input port for each > module in the project so that when these input ports are set, the > modules start working. > > According to my knowledge in verilog, we could call the entire project > or all the modules together by setting all the input ports. But what > we want is,calling different modules of the project at different times > or calling one module more than once and other modules only once.(I > hope you understand this).I have tried to set the input ports > sequentially but only the last call or the last call of the module is > onlly executed.All the before calls are not getting executed. > > Here are my some modules in the project > > module project: > > case(state) > > IDLE: begin > > if(reset =3D=3D 1) begin > > ----- > > -------- > > ------- > > next_state =3D STATE0; > > end > > STATE0: begin > > if(inititate_i =3D=3D 1) begin > > --------- > > --------- > > --------- > > next_state =3D STATE1; > > end > > else > > next_state =3D IDLE; > > end > > endmodule > > My main program from which I called my project is - > > mainprogramme: > > main project instance; > > main project reset =3D1; > > main project inititate_i =3D 1; > > main project reset =3D 1; > > endmainprogramme > > In the above case, only my second call of the reset is being > executed(I have written code in my project which will retain my old > values of the register,so there is no worry of that may be the values > are getting overwriiten). There is a simple way of calling the > different modules in the main project by just using a counter and > running t he module as many times as i require. But we don't want > that, beacuse the number of times a single module is called is not > decided before. > > Could any one please give me suggestions for solving this probelm.I > would be great ful for the help. > > Please help me. I have been trying on this problem from many days but > with no success. It appears that you are trying to apply software design conventions to a hardware design and it really doesn't make sense. You are designing for an FPGA and the hardware logic that you are describing is always present and always running in parallel. Hardware logic modules are not "called" as you would with a software sub- routine they are instantiated and always present. Ed McGettigan -- Xilinx Inc.Article: 147968
Hi Guys, I am just wondering if there are any standard ways of disabling an ip core after an evaluation period of say 30 days. I am trying to provide a potential customer a ip core but don't want them to continue using it after the eval license period expires. The core will run on Xilinx Spartan3 FPGAs. Any suggestions will be much appreciated. Regards SudhirArticle: 147969
> I am just wondering if there are any standard ways of disabling an ip > core after an evaluation period of say 30 days. If the target doesn't have a real time clock, or some other way to access the time (e.g., an internet connection), then there's no obvious way to do it. What Xilinx does for their own evaluation cores is make them stop working after a certain number of clock cycles from power-up, so that you can see that it works for a while, but to keep it working, you have to keep resetting the hardware.Article: 147970
Sudhir Singh <Sudhir.Singh@email.com> wrote: > I am just wondering if there are any standard ways of disabling an ip > core after an evaluation period of say 30 days. I am trying to provide > a potential customer a ip core but don't want them to continue using > it after the eval license period expires. The core will run on Xilinx > Spartan3 FPGAs. Considering the ability to change the date on the computer, it is pretty hard to stop people from using something past a given date. Once the bit file is generated, it is pretty much impossible. The only ways I can think of would require a response from you. One possiblility is that you (on your machine) do the actual synthesis and P&R. Otherwise, if the license agreement has a large penalty for using it past 30 days, and you catch them using it... -- glenArticle: 147971
Hi Eric, Thanks for your reply. I don't have access to a real time clock so I guess we'll have to live with having to reset the board. Cheers Sudhir On Jun 9, 12:16=A0pm, Eric Smith <space...@gmail.com> wrote: > > I am just wondering if there are any standard ways of disabling an ip > > core after an evaluation period of say 30 days. > > If the target doesn't have a real time clock, or some other way to > access the time (e.g., an internet connection), then there's no > obvious way to do it. > > What Xilinx does for their own evaluation cores is make them stop > working after a certain number of clock cycles from power-up, so that > you can see that it works for a while, but to keep it working, you > have to keep resetting the hardware.Article: 147972
Hi, I'm somewhat familiar with synthesis and Verilog but I am quite new to running the designs on FPGAs. I have a complex design of a processor that I am trying to get running on a Virtex 5 FPGA in a BEE3 module. The design synthesizes and goes through translate, map and par in Xilinx ISE 10.1 but it does not seem to run correctly when programmed on the FPGA. ISE says that all timing constraints have been met and the static timing report shows that it does too. What I am going to do now is look at the post-par simulation and see if there's a problem. Is there anything that maybe is a common mistake that I should also look into? I am using a DCM to turn the 100 MHz system clock into a 50 MHz clock. Any suggestions will be appreciated. Thanks, Brandon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147973
On 6/9/2010 8:01 AM, BrandonD wrote: > Hi, > > I'm somewhat familiar with synthesis and Verilog but I am quite new to > running the designs on FPGAs. I have a complex design of a processor that I > am trying to get running on a Virtex 5 FPGA in a BEE3 module. The design > synthesizes and goes through translate, map and par in Xilinx ISE 10.1 but > it does not seem to run correctly when programmed on the FPGA. > > ISE says that all timing constraints have been met and the static timing > report shows that it does too. What I am going to do now is look at the > post-par simulation and see if there's a problem. Is there anything that > maybe is a common mistake that I should also look into? > > I am using a DCM to turn the 100 MHz system clock into a 50 MHz clock. Any > suggestions will be appreciated. > > Thanks, > Brandon > > > > --------------------------------------- > Posted through http://www.FPGARelated.com Anything other than single clock synchronous logic isn't represented in your timing constraints; so anywhere that you're using a clock other than your derived 50 is worth another look. This includes any logic running off of a combinationally gated clock. You said you're used to synthesis but not FPGAs; if that means ASICs then one thing to be aware of is that clock nets are a lot more sacred in FPGAs. Unless you've specified your external OFFSET IN/OUT constraints properly (this is rare), then your constraints don't properly cover your relationships to external hardware. Worth another look. -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 147974
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Sudhir Singh <Sudhir.Singh@email.com> wrote: > >> I am just wondering if there are any standard ways of disabling an ip >> core after an evaluation period of say 30 days. I am trying to provide >> a potential customer a ip core but don't want them to continue using >> it after the eval license period expires. The core will run on Xilinx >> Spartan3 FPGAs. > > Considering the ability to change the date on the computer, > it is pretty hard to stop people from using something past > a given date. Once the bit file is generated, it is pretty > much impossible. Well, at least the licensable Xilinx IP I've used included some kind of timer in the bitfile itself if there's no license, so that the block works for a few hours and then quits.
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