• Content count

  • Joined

  • Last visited


Community Reputation

0 Neutral

About Adrian

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Currently, as far as I know, you cannot infer the following constructs with BRAMs - dual clock domains, byte enables, and different word sizes between reads and writes. If you were trying to infer a BRAM with a byte enable, the synthesis tool may have been unable to construct it properly in order to replace it with a BRAM primitive. Have you thought about have a different file for simulation / testing then you have for synthesis / P&R? Test your code with your inferred BRAM with byte enable, then switch over to using a primitive instantiation / pcore when you actually need to synthesis. I agree with you about ISE, by the way, it is quite clunky.
  2. The following seems a little clearer, at least to me: begin process (Clock) begin if rising_edge(Clock) then if Enable = '1' then if WriteEnable(0)='1' then RAM0(conv_integer(Address)) <= DataIn(7 downto 0); else DataOut(7 downto 0) <= RAM0(conv_integer(Address)) ; end if; if WriteEnable(1)='1' then RAM1(conv_integer(Address)) <= DataIn(15 downto 8); else DataOut(15 downto 8) <= RAM1(conv_integer(Address)); end if; end if; end if; end process; end Behavioral;
  3. Additionally, looking at the code again, do0 and do1 are both going to implemented as latches - they aren't set on every branch of the conditions. You are going to want to set them to some value when WriteEnable(0) and WriteEnable(1) are true, not just when they are false.
  4. Hi Earlz, Your process that reads the BRAM values isn't reading them synchronously, but rather concurrently; you want to read data out of the BRAM in a process that only has the clock in its sensitivity list. Thats what the error is warning you about. More importantly, though, you can't implement byte enable natively in BRAMS on a Virtex 3e, as far as I can tell; from the Xilinx BRAM Data Sheet: RAMB primitive in architectures prior to Virtex-4 only have a single write enable per port. Thus if byte-write enable is required on a 32 bit data port (C_NUM_WE=4), these architectures will use a minimum of 4 BRAM primitives. If you can deal with a few cycle latency between reads and writes, you can implement byte-enable in logic around the BRAM, but it would really matter on your application design - let us know more details, and we can try and help you with a good fix. -Adrian
  5. Adrian

    Arduino Library Support?

    Alvie, Ah, thank you. I hadn't realized how trivial they were, I merely saw they didn't work and wanted to see what the status was on the arduino libraries. Thank you again! Adrian
  6. Adrian

    Arduino Library Support?

    Alvie, Thank you, I was more curious what the status was on the arduino libraries, and how important it was to have sketches be platform independent across the Zpuino. The only other functions (macros) I need now are digitalPinToPort, digitalPinToBitMask, and portInputRegister, although if those need specific AVR registers, maybe the best course of action is to just rewrite this sketch to work with the Zpuino. Adrian
  7. Adrian

    Arduino Library Support?

    Aaah, my mistake. I thought the ZPUino was an AVR clone.
  8. Hi Alvie, let me address your two questions separately: ROCCC is not really an HDL like SystemC, but rather a compiler for C kernels down to RTL VHDL. You dont so much "describe" your hardware in ROCCC as you write the equivalent C code that would implement that algorithm. To give you an extremely simple example, a 4-tap FIR filter acting on a stream of data would be coded in ROCCC like this: [tt] typedef int ROCCC_int32; void FIRSystem(ROCCC_int32* A, int length, ROCCC_int32* { for(int i = 0; i < length; ++i) { B = A[i+0] * 1 + A[i+1] * 3 + A[i+2] * 5 + A[i+3] * 7; } } [/tt] ROCCC then optimizes the datapath and access windows, and generates RTL VHDL that implements the same algorithm. Again, ROCCC is designed specifically for stream-based kernel calculations; you do not write your entire hardware algorithm in ROCCC. I've put a great deal of effort into making sure the code generated by ROCCC performs well in terms of frequency and throughput; area, often, is sacrificed for these goals, but ROCCC targets the domain of high-performance computing, where this is generally acceptable. In terms of throughput, ROCCC is generally very well performing; for example, I was able to get 1.76 GB/s throughput implementing SHA1 from C in ROCCC, compared to a commercial SHA1 ASIC ipcore that gets 2.185 GB/s throughput. For an automated tool, that is pretty impressive, especially considering we are going to an FPGA rather than an ASIC. ROCCC implements automatic register placement along critical paths to help aid timing; this is guided by the user supplying estimates of the delay of basic components, such as adds or multiplies, and also a desired goal frequency. In this way, area / frequency tradeoffs can be explored, without needing to rewrite the source C code. That is the main gist of ROCCC, I am not 100% sure if ROCCC is a good match for the sorts of things hobbyists are interested in, but I would love to see an example application come up. The most likely application would be an audio or video coprocessor.
  9. Adrian

    Ultimating 1.0 release.

    I am getting the same thing - it doesn't look like its an issue, though, just an annoyance, as clicking close doesn't actually close anything, and I can continue to compile and upload to the Papilio.
  10. Jack - Sounds interesting! I'd love to help out, audio stream processing, such as FFT, is actually a decent fit for what ROCCC is designed for. More importantly, I'd be very interested in some audio libraries - a friend and I are working on digital effect stomp boxes, but we are really running into the limits of (cheap) software, and the obvious next step is to move to hardware.
  11. Adrian

    Arduino Library Support?

    Hi all, I just got my Papilio 250 and have been playing around with the ZPUino and associated Arduino IDE for a day or two now. Right now I'm curious who is developing support for the Arduino libraries - is it gadget factory, or is it ZPUino? I ask because there are quite a few missing functions that are normally supplied by Arduino (shiftOut comes to mind) as well as the ones supplied with avr (avr-lib). Is there any plans to implement these missing libraries to make sketches truly cross-platform? Or are these already working, and I am just missing a critical step to getting my sketches compiled onto the ZPUino? Thank you!
  12. Sorry for resurrecting an old thread, but I just got my papilio and jumped onto the forums, and I thought that I would be the best person to answer this, seeing as I worked on the ROCCC 2.0 backend. ROCCC really wasn't built for general purpose EDA, but rather for optimizing datapaths embedded in loop nests; I can imagine that most users of a small development board, like the Papilio, will get more usage out of a soft processor than out of a core created through ROCCC. If you really want to embed a ROCCC core, most likely the biggest hurdle you will find with porting a ROCCC core to something like the papilio is space constraints; ROCCC optimizes for throughput, not space, so throwing a big datapath into 250-500k gates will probably be difficult. That being said, I would love to get a ROCCC core working next to a soft processor, I just can't think of an example application!