Jon W

Members
  • Content count

    13
  • Joined

  • Last visited

  • Days Won

    1

Community Reputation

1 Neutral

About Jon W

  • Rank
    Member

Profile Information

  • Gender Not Telling
  1. The next generation Papilio - help me shape it.

    There are two kinds of EEs: Those who design antennas on purpose, and those who build antennas accidentally :-)
  2. The next generation Papilio - help me shape it.

    If I were to invest time in learning anything other than Eagle, and I had to finance it myself, I would probably go with KiCad. It's open source, free as in all kinds of beer and speech, and seems fairly capable. The workflow is a little different; you don't assign footprints for components until you go from schedule to board, rather than building libraries with footprints paired. Also, there seems to be some minor redraw glitches that are annoying. Bonus: Runs on many OS-es. SIncerely, jw
  3. The next generation Papilio - help me shape it.

    You mean, other than just "cute"? No idea :-) Also, you won't get them under $100/each unless you want at least 5 (you pay $480 for the batch...)
  4. The next generation Papilio - help me shape it.

    I'd like to second the call for low-cost boards. I started out as a software guys with hobby electronics background, and I've been keeping a quarter of an eye on FPGAs for a very long time. However, nothing has pushed me into actually learning about them, until I got to an application where the built-in peripherals in an MCU aren't enough -- I need a large amount of quadrature decoders, cheaply, with a very small amount of logic. Even so, paying the $70 or so for the Papilio One + Logic Start MegaWing was a barrier that kept me away from it for about six months, before I could finally take that plunge. If the price had been substantially higher -- say, over $89 to get started -- I may never have taken the plunge. Meanwhile, the 250k gate-units in the One 250k is just fine for me; I don't have any plans to take the world by storm with a speculative-execution free CPU core or anything ;-) Personally, I'm not as excited about the Arduino form factor. There are a lot of shields, true, but I find that most of them are not right for my projects. In the low-power MCU world, I'd much rather use a bare, DIP, Atmega, and a soldered breadboard or a quick PCB from some place like OSH Park, to get where I need to go. Also, the Arduino shields/pinouts are criminally short on GND pins, and also somewhat short on supply pins; for any "real" system you have to break those out using some other method anyway. I find the Papilio wing system to be much better for this purpose, honestly.
  5. I don't recall seeing that for the BUFG component in the ISE output. If I had, I'd not have been surprised! Maybe BUFG is special somehow...
  6. Let me be clear. When I say "synthesize," I actually mean "synthesize, map, place&route, build bit file." That all works, without pulling any library, when referencing a BUFG. When I run in simulation, it compiles, links, and executes, without giving me any error; the end result is just I get faulty behavior. This, to me, is a silent failure, which is the worst! By comparison, if I use a C library, include the right header file (or pre-declare the prototype) but don't link with the library, I will get a link error, and it will not get to the "execute" (or even complete the "build excutable") part. Regarding the warning I was talking about: I'm adding the BUFG because I got a warning that my derived clock signal may skew too much. (For that to be true, it would have to split my component into different distance implementation elements, but I guess that might happen if it was a very full design?) So, I added the BUFG. And got a silent failure in simulation. Which was highly surprising. So, to explain this surprising behavior, my mental model is now something like: "The hardware synthesis path (all the way to bit file) is a totally separate tool chain than the software emulation path. The default libraries/components included do not perfectly match. And, for certain components, if you forget to include a particular library, you may get a silent failure that executes but doesn't give proper results, not an explicit link error like you'd get in C." So, is there a way I can crank up the warnings/errors to actually get told what's missing in the simulation case?
  7. Serial port RTS question

    If I understand the concern, I have some additional information: The USB bus already has such a system. Each endpoint has a fixed max size, and no more than that can be outstanding at a time (plus double-buffering if supported.) Now, if you're sending 1.2 kB of data per second to the host, and the host is not actually receiving and processing 1.2 kB of data per second, then something will drop somewhere. More than likely, the FIFO in the FTDI will fill up, and then the FTDI will drop the data. This is much more likely than the host dropping the data (unless you're using very shitty serial-USB drivers.) So, does the FTDI document the size of the FIFO? IIRC, the max size of a USB full-speed endpoint is 64 bytes, but the FTDI could conceivably have a deeper buffer. Hardware flow contrl between FTDI and FPGA would totally solve this, though -- host need not be involved. (But then, the data will back up on the FPGA side -- it has to back up somewhere :-) Also, have you considered using a USB microcontroller instead of the FTDI chip? If you need some microcontroller for analog ins or flash bootloading or whatever, then that might be able to do double duty. Or it might change the design more than it's worth!
  8. Hmm. Without "pulling" the library, it actually synthesizes fine. And, in C, if I'm missing a library, I get an obvious link error, not just silent failure. In fact, silent failure is i.m.o. THE WORST in any kind of engineering :-)
  9. Thanks! Neither the book I'm using, nor the Xilinx documentation on the BUFG component, actually mentioned this, so I would have been totally in the dark without this answer. Actually, to make progress, I replaced the BUFG with a straight wire and lived with the "clock skew" warning, but now I can go back to the right way of doing it!
  10. The next generation Papilio - help me shape it.

    A comment from a newbie here. If the "golden images" for shields is on the base board, then that means that: 1) only the number of shields that fits in the golden image space will ever be supported 2) if I want to ship a new kind of shield, how would the code for that shield get into the image? Wouldn't it make more sense to put the code for the shield into a smaller flash chip on the actual shield? Like game console cartridges, or PC expansion card boot ROMs?
  11. I'm using Xilinx ISE 14.7 to program a Papilio One 250k. I'm trying to simulate a process that uses a BUFG component, and the output of the component is all 0 -- it doesn't follow the input. Here's a small snippet of code: library IEEE;use IEEE.STD_LOGIC_1164.ALL;use IEEE.NUMERIC_STD.ALL;entity UART is Port ( CLK : in std_logic; -- CLK runs at 32 MHz CLKDIV : in unsigned(15 downto 0); -- divide to bit clock );end UART;architecture Behavioral of UART is signal BITCLK : std_logic := '0'; -- four clocks per bit signal PREBITCLK : std_logic := '0'; component BUFG port( I : in std_logic; O : out std_logic ); end component;begin Bitclk_Bufg: BUFG port map( I => PREBITCLK, O => BITCLK ); Clk_Proc: process(CLK, CLKDIV) variable PREVDIV : unsigned(15 downto 0) := to_unsigned(0, 16); variable CURCNT : unsigned(15 downto 0) := to_unsigned(0, 16); begin if rising_edge(CLK) then if not (PREVDIV = CLKDIV) then CURCNT := to_unsigned(0, 16); PREVDIV := CLKDIV; elsif CURCNT = PREVDIV then CURCNT := to_unsigned(0, 16); PREBITCLK <= not PREBITCLK; else CURCNT := CURCNT + 1; end if; end if; end process;...I see CLK coming in in my simulation, and I see PREBITCLK being generated. However, the BITCLK output is just 0 no matter how long I run the simulation. Why is this? Isn't it supposed to just buffer the clock, and thus repeat the input? How can I make it do that?
  12. The problem turned out to be the specific USB port I was using. When connected to the USB3 port at the top of my screen, the programmer doesn't work. When connected to the USB2 port in the detachable keyboard, it works fine!
  13. I recently bought a Papilio One 250k and a Logic Start MegaWing from Seeedstudio.com. I downloaded and installed the ISE 14.7 (after replacing the compatibility DLL to make it run on Windows 8.) I can compile the first few sources from the FPGA VHDL intro book (switches_leds) Then I downloaded and installed the Papilio Loader version 2.6. I followed the instructions to cancel driver installation, and let Windows do it. When I plug in the Papilio One, two COM ports appear (COM4 and COM5) and the red power LED on the board turns on and the eight green LEDs on the MegaShield light up. When I point it at my bit file, and try to program it, first nothing happens, and then I get the following error: