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
"Roberto IZ5FCY" <iz5fcy_NOSPAMPLEASE_@arrl.net> wrote in message
news:wzb56p4xowzg$.1um668ma1y2vm.dlg@40tude.net...
>
> > If you're using an 8-bit microprocessor, simply translate doing long
> > division by hand into steps of subtract, store if positive/jump if
> > negative, shift and bring in new bits. If you can't do long division by
> > hand, you're hosed.
>
> Thanks John, but in "C" language....??
int can_solve_problem(usenet_poster *op)
{
if (op->can_do_long_division)
{
think(op);
write(op, SOME_CODE);
return 1;
}
else
{
hosed++;
return 0;
}
}
Article: 97976Hi there wrong! AVR GCC suports int (16bit) long, and long long. Aurash Roberto IZ5FCY wrote: > > >>If you use a C compiler, it probably knows how to do math with long values... > > > No dear Uwe, the 8bit PIC or AVR don't have 16bit math library.... >Article: 97977
If your PIC doesn't have a math library that can handle the large numbers, do it with an array of 8-bit integers or chars. Loop through the 8-bit values the way you loop through the digits to do long division. If your base frequency will never change, however, forget calculating 2^n*Fout/Fclk but instead perform the multiplication of Fout*const where const=2^n/Fclk. You may need to calculate the constant by hand, but you end up with a number that will give you your phase increment value for your DDS with a simple multiplication. If the PIC's C support doesn't provide multiplies for numbers that big, try doing multiplication "by hand" in C.Article: 97978
Isn't 'wrapped_dpram' a VHDL file? Include it in your project or cut & paste the code into your original file. if wrapped_dpram is the black box instantiation and the tool generated an .ngo or .edf file, John Adair's suggestion gets you going.Article: 97979
Thanks John.. -- 73's de IZ5FCY RobertoArticle: 97980
> What about "long long"? Depends on your compiler, but if it is > available, it may be 64 bits wide. > > If there is no suitable data type, then you need to handle the carry-out > manually. Unfortunately C does not let you access a carry flag inside > the CPU. So you got two choices: Make the most significant bit the > carry-out and handle it manually or use inline assembly. Inline assembly > is quite easy to handle for GCC. Thanks Ralph! > But I think, we are very off-topic! I'm sorry, but before FPGA implementation... where I could find one large reunion of "great brain people" like this? :-))) Bye.. -- 73's de IZ5FCY RobertoArticle: 97981
Use 2 1Wr2Rd RAMs that are in your library. Rather than writing a value to both RAMs, write the XOR of the read value from the other RAM with the write data. To read the valid data, read the value in both RAMs and XOR them. The read XOR will provide the last data written to that location. This gets you most of the way. If you have a write to both ports at the same address - invalid in some dual-port memories - collision arbitration needs to decide who gets the write; the winning RAM writes, the losing RAM doesn't. If both RAMs write in a collision, the data is invalid. If you guarantee that two writes to the same location never occur at the same time, the only constraint is that writes to the same address are never too close (write data becomes valid for read in RAM1 before RAM2 uses the read data to update that address in RAM2). This should give you 100% dual-port RAM without too much trouble. You then only need to worry about the 1Wr2Rd RAM behavior as far as async vs sync read-first versus sync write-first. Yay?Article: 97982
Roberto IZ5FCY wrote: >> But I think, we are very off-topic! > > I'm sorry, but before FPGA implementation... where I could find one large > reunion of "great brain people" like this? :-))) Look for mailing lists. Look at the website of the compiler you use. If there is GCC available for your MCU, then its quite possible, that there is a mailing list - and a documentation and a FAQ... RalfArticle: 97983
Roberto IZ5FCY wrote: > Hi to all Newsgroup, > > I need of your little help. > > With an 8 bit microcontroller I must to calculate the AD9558 DDS input > data, with the formula: > Data = (2^48/Fclk)*Fout > > i.e. : > Fclock =100MHz > Fout = 11300000 Hz > Data = 1CED 9168 72B0 or 31,806,672,368,304 > > With an 16 bit processor I don't have any problem, but with an 8bit > processor I don't find/know the right way to calculate the *exact* Data. > Have you an solution?? > Thanks in advance and sorry for bandwidth... > > -- > 73's de IZ5FCY Roberto Use the shift and subtract method : http://www.8052.com/div16.phtml This method is suited for 16-bit but can be easily extended to your bit length.Article: 97984
Hi i was wondering which would be the best way to get the PPC on a virtex II pro to control the 4 inputs on a LUT, so far i have tried using GPIO/IPIF (using xilinx EDK create import peripheral dialogue) to control registers over the plb or opb bus but how would i instantiate a xilinx primitive element lets say a srl16 and connect 4 of the register values to its inputs and one to its output? Is this approach even possible has anyone tried driving the inputs on internal fpga elements? any ideas help would be greatly appreciated thanks shaneArticle: 97985
Hi All, I have some problems using SoPC builder (5.1) with DMA and PCI (Altera PCI compiler 4.1.0). I have system with PCI with 4 BARs, 4 user interfaces (three of them are actually memories, but implemented outside of the system) and DMA controller. The PCI has this configuration: BAR0 1MByte, prefetchable - user memory BAR1 32kBytes, nonprefetchable - control io BAR2 4kBytes, nonprefetchable - control memory1 BAR3 1kByte, nonprefetchable - control memory2 "control io" is is connected to control port on DMA, CRA registers on PCI and some registers outside of the system "user memory" is main memory of the system. the DMA controller has connected its read port to PCI access, write port to the "user memory". it is configured to use burst transfers of 128 bytes, uses only words (because the PCI is 32bit), and it has 20bit length register. The first problem The DMA has 20bit length register. But when I write to the Length register anything that is longer than 10 bits, the DMA stops responding and does nothing. The way to produce is write 0x8C to the Control register (GO, Words only, Length=0 stop), zeroing the Status register and then write to the Length register. With lengths smaller than 0x400 it works fine. And the second one I haven't found how to use IRQ of the DMA - is it functional? Maybe it is problem of PCI megacore... I want to create a PCI interrupt after end of DMA operation to let the control driver know that the operation is finished. I have enabled interrupts from Avalon (bit 7 of register 0x14 in PCI CRA), then I have set the I_EN bit in DMA Control register (bit 4), but the interrupt does not happen. It is also weird, that I dont see any IRQs in the SoPC builder, but the PCI should support IRQ... Do you anyone know, where could be the problem? Any help appreciated, MartinArticle: 97986
If you want to have a tiny and very fast solution you can use the OCM interface and directly connect logic resources to it. UltraController-II should give you a good starting point to accomplish this. See XAPP575 for more information (http://www.xilinx.com/bvdocs/appnotes/xapp575.pdf). - Peter munch wrote: > Hi > i was wondering which would be the best way to get the PPC on a virtex > II pro to control the 4 inputs on a LUT, so far i have tried using > GPIO/IPIF (using xilinx EDK create import peripheral dialogue) to > control registers over the plb or opb bus but how would i instantiate a > xilinx primitive element lets say a srl16 and connect 4 of the register > values to its inputs and one to its output? > > Is this approach even possible has anyone tried driving the inputs on > internal fpga elements? > > any ideas help would be greatly appreciated > thanks > shane >Article: 97987
Excelent point. Why 48 bits? If you need to provide a 3Hz signal with 1ppm accuracy from a 100 MHz clock, that's roughly 35 bits. If the accuracy requirement is determined different from raw frequency, a limited number of bits could be used with a simple shift, much like a floating point value.Article: 97988
I'm currently working with ISE 7.1 I'd like to be able to assign FPGA pins to a submodule either via a ucf file, or (preferably) via assigning properties to nets within the module. To expand-- I'm creating some modules for use as library blocks in a classroom setting. These blocks will always be mapped to static FPGA pins, corresponding to LEDs, pushbuttons, etc, so I'd like to be able to just drag and drop them onto a schematic, without having to create top level I/O markers. I know this was possible in ISE 2.1 (the version the class is currently using), but is it still possible in 7.1? Thanks, MattArticle: 97989
I have a Spartan 3 starter kit. Im going to build an expansion board that will have some more components on it. does anyone know where i can get some examples? or guides to do this? i know im going to use a standard 2x20 right male connector, and i the pin functions. but an example board would be most helpful. i also want to attach some sma connectors on it to get testpoints. the plan might be.... build pcb layout, have expert review design, produce gerber, and send to be printed. someone recommended 33each.com pzArticle: 97990
fpga_toys@yahoo.com wrote: > Being really retro would be taking a hand full of floppy drives apart > for their heads, collecting some 1" mag tape and glue to a cylinder, > and building a drum. Or maybe machine up a nice drum, and have it > nickle plated, for the real thing :) Being really retro would be building an ABC computer. Has anyone since Babbage tried to build a Babbage Engine?Article: 97991
Does anybody know if the ISE WebPack environment support the Bitstream encryption in the Vertex II devices? Thanks ahead of time. ScottArticle: 97992
zhangweidai@gmail.com wrote: > I have a Spartan 3 starter kit. Im going to build an expansion board > that will have some more components on it. does anyone know where i can > get some examples? or guides to do this? i know im going to use a > standard 2x20 right male connector, and i the pin functions. but an > example board would be most helpful. i also want to attach some sma > connectors on it to get testpoints. > > the plan might be.... build pcb layout, have expert review design, > produce gerber, and send to be printed. someone recommended 33each.com > > pz Hmm... 2x20.. Sounds like the connector that Digilent uses on its boards. They also sell accessory boards, which seemed to be reasonable priced. They won't have SMA connectors, though. Even if you don't buy from them, you may get some ideas from looking at their site (www.digilentinc.com). And no, I don't work for them, but I have bought some boards from them. -Dave PollumArticle: 97993
We have been talking about Broaddown4 for a long time and finally you can get the first viewing here http://www.enterpoint.co.uk\moelbryn\broaddown4.html . This is just a show model that we are taking to DATE and you can see it in the flesh there. We can also talk you through some of the features not listed on the website yet. Eagle eyed among you will see some bits missing like the LM4600 switchers and the 700 MHz clock generator chips so we won't be powering one properly for a couple weeks yet. It isn't quite as big a beast as Broaddown1 for select few of you that know of that product. However it is knocking on the door of it's capabilities but the double disk drive power input has been put there for a reason. We have given the board a potential power envelope of 240W+ in it's meanest form but you are going to have wait a while before that version is in the marketplace. As with all our products you can use it stand-alone on the bench and don't need to plug it into a PC slot. First versions that are likely to available will be LX40 and SX55 based. We have parts stock these ready for the roll out. Other versions will roll out as fast as we can and based on demand. Given the board has 36 different possible Virtex-4 combinations (1296 possible if you count the Moel-Bryn sockets) there will some limitation on the standard range stocked but as always we can do special combinations to order. P.S we still have some room on the back of the board for some more features so please do make (nice) suggestions what we might do with it. We have one more cut of the board to make before first production units go out and will consider all reasonable ideas for inclusion. John Adair Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development Board. http://www.enterpoint.co.ukArticle: 97994
Nial Stewart wrote: > > Placement for some variables used at the top of the pci process created > > some longer combinatorial chains than I had expected. Placing them at > > the bottom of the function will remove the deep combinatorials, and > > leave that path much shorter from the registered version of the > > variables. > > You've had to understand the target architecture and what's causing your > timing constraint to fail, then re-jig your HDL to reduce the number of > levels of logic to achieve timing closure. > > I thought that one of the arguments for using a C based HDL was you can avoid > this level of design implementaion detail? Not at all. Programmers juggle instruction/statement flow all the time to reach timing closure in C and asm for device drivers and embedded applications in many fields .... such as software driven stepper motor controls. Such low level programmers also have training in understanding bit level device interfaces, and related timing. They frequently do not have board level hardware training or experience, to deal with power, board level signal integrity, and related issues. The reason for C based HDL/HLL's is to expand the field to include related sytems and embedded programming talent to be able to effectively, and comfortably, write "programs" for HDL/HLL FPGA based designs which effectively instantiate the same hardware that VHDL/Verilog would with similar syntax statements. We do this by preserving sequential semantics with parallel statement execution of standards based C. Also removing fine grained access to creating multiple fine grained clocking sematics that are standard for pure HLLs. For those that are doing device level or machine level interfaces, writing C FSMs to netlists is substantially the same as coding asm or C for similar low level hardware interfaces. Remarkably the same task and skill set as writing drivers or embedded hardware controls. Programs are FSM's and data paths.Article: 97995
Not sure if this is relevant to your problem anymore, but I found the problem with my design (briefly described above). There is only one signal that can be assigned in the dsbram_if_cntlr, that is BRAMDSOCMCLK. We were running our PPCs at 200MHz and our PLB bus at 100MHz using proc_clk_s and sys_clk_s, respectively. It was such a habit to assign all non-processor clks to sys_clk_s, that we did so for BRAMDSOCMCLK. After reading the data sheet for dsbram_if_cntlr, we found that the BRAMDSOCMCLK signal needed to be 1-4X the processor clk. The slow clock we gave to the BRAM caused our unpredictable behavior. If anything, I have learned to read those data sheets a little better. This may or may not be the same as your problem, Jeff, but thought I would follow up with the fix we came up with for our system. We are running a prodcuer/consumer type system as well and haven't had any problem with inconsistencies. The shared BRAM is a circular FIFO in our system. I could provide details on its operation if you still have trouble with your system.Article: 97996
Nial Stewart wrote: > You've had to understand the target architecture and what's causing your > timing constraint to fail, then re-jig your HDL to reduce the number of > levels of logic to achieve timing closure. Looking at the problem a little more this afternoon, the C based 66mhz PCI core is looking much more viable. The combinatorial length was actually from unnecessarily including the main references to the pci bus signals in the else side of the reset conditional. Breaking that dependency changed the base FSM speed from 63mhz to better than 73mhz, making it likely the other setup and hold times can be met as well. I suspect the remaining code to be written will not change this, and I can refine what is there a bit better, possibly improving this so my other board with -6 parts can be used at 66mhz as well. Probably by hacking the ucf file some more to optimize placement for the bus interface slices to use the local IOB to CLB routing, and get rid of the longer general routing paths ISE is using, since routing delays appear to be better than 60% of the timing budget. Timing summary: --------------- Timing errors: 0 Score: 0 Constraints cover 1569 paths, 0 nets, and 1215 connections Design statistics: Minimum period: 13.556ns (Maximum frequency: 73.768MHz) Maximum path delay from/to any node: 13.556nsArticle: 97997
Matt Fornero wrote: > I'm currently working with ISE 7.1 > > I'd like to be able to assign FPGA pins to a submodule either via a ucf > file, or (preferably) via assigning properties to nets within the > module. > > To expand-- I'm creating some modules for use as library blocks in a > classroom setting. These blocks will always be mapped to static FPGA > pins, corresponding to LEDs, pushbuttons, etc, so I'd like to be able > to just drag and drop them onto a schematic, without having to create > top level I/O markers. > > I know this was possible in ISE 2.1 (the version the class is currently > using), but is it still possible in 7.1? > > Thanks, > Matt Before you go too far with this, you may want to use the schematics in 7.1i a bit. You may not want to use the new schematics at all... Just my 2c GaborArticle: 97998
Michael Hennebry wrote: > fpga_toys@yahoo.com wrote: > > >>Being really retro would be taking a hand full of floppy drives apart >>for their heads, collecting some 1" mag tape and glue to a cylinder, >>and building a drum. Or maybe machine up a nice drum, and have it >>nickle plated, for the real thing :) > > > Being really retro would be building an ABC computer. > > Has anyone since Babbage tried to build a Babbage Engine? > I had a working model of the Babbage computer somewhere around 1972 made of plastic. As I recall, it took a fair bit of sanding and lubricating to make it work smoothly. I don't recall who made the kit, or even where I got it.Article: 97999
Hi, I'm trying to measure program execution time in Platform Studio. I use two clock() functions from time.h before and after the code section I want to take the measurement. When I compiled the program, I received the following errors: /cygdrive/c/EDK/gnu/powerpc-eabi/nt/bin/../lib/gcc/powerpc-eabi/3.4.1/../../../../powerpc-eabi/lib/libc.a(timer.o)(.text+0x10): In function `_times_r': /cygdrive/x/gnu_builds/halite/env/Jobs/MDT/sw/nt/gnu1/ppc_newlib_src/newlib/libc/reent/timer.c:64: undefined reference to `times' /cygdrive/c/EDK/gnu/powerpc-eabi/nt/bin/../lib/gcc/powerpc-eabi/3.4.1/../../../../powerpc-eabi/lib/libc.a(timer.o)(.text+0x68): In function `_gettimeofday_r': /cygdrive/x/gnu_builds/halite/env/Jobs/MDT/sw/nt/gnu1/ppc_newlib_src/newlib/libc/reent/timer.c:108: undefined reference to `gettimeofday' collect2: ld returned 1 exit status Does anyone know what's wrong? Thanks plenty! -Eric
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