Gau_Veldt

Members
  • Content count

    17
  • Joined

  • Last visited

  • Days Won

    2

Gau_Veldt last won the day on January 8

Gau_Veldt had the most liked content!

About Gau_Veldt

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Interests
    Computers, AI, Games, hardware and software Coding, FPGA, retro computing, consoles
  1. Feedback on a register file design?

    What's going to happen here is that the synthesizer is going to generate your design and optimize out any signal assignments that cannot be reached (or that are reached but overridden by a later assignment) on a particular path through the process. All possible paths that modify a particular signal are then strung into a MUX determining that signal's value. There will be one such MUX for each different signal the process assigns to (and in this case each MUX will also be coupled to a register clocked by someClock). It's not like a programming language where a series of assignments will be run in order. So a process like: someProc: process(someClock) is begin if (rising_edge(someClock)) then mySignal <= oneSignal; mySignal <= anotherSignal; mySignal <= oneMoreSignal; end if; end process someProc; Will synthesize (elaborate) to a register called mySignal whose input connects to oneMoreSignal and whose clock input is connected to someClock. oneSignal and anotherSignal won't even appear in the elaboration of someProc.
  2. Performance of FPGA vs GPU?

    Just to put in perspective 2^256 is a base ten number with around 77 zeros. Let's divide this by 1000 THz for an imaginary design running at 1 PHz (petahertz which has 15 zeros) that can do the entire elliptic curve, ripemd160 and comparison to your target hash in one clock cycle (this pure fantasy is to simplify things by starting from a whopper hyperbole of a best possible design that cannot be achieved in practice). Now we're at a number with around 62 zeros ~= 10^62 or so seconds. 60 seconds is one minute, 3600 seconds is an hour, 86400 a day, 3.162*10^7 is a year (around 31.6 million). If we divide this into 10^62 we get around 3.66 * 10^54 years on an imaginary device that does a complete crack attempt for one 256-bit guess on a 1 petahertz clock. If you had 1000 of these devices you'd only cut the exponent by around 3 (10^51) ideally and a million devices (10^6) only lowers the exponent by 6 to get 10^48. Ten billion (one of these ultra fast rigs for every man woman and child on the planet) only lowers the exponent by 10 to get 10^44. 3.66 * 10^44 YEARS. By then our sun will no longer be lit thus you likely won't be around to see the bitcoins when the key is cracked even with ten billion of these hypothetical 1 PHz devices that cannot be built with any of today's existing technology. A 64-bit number, which is the keyspace you actually need to attack, is marginally more doable: 5.834*10^11 years so if every man woman and child on the Earth had one of these 1 PHz rigs (a botnet of pure fantasy) it would take 5.834 years. A minimal FPGA board at around $100 runs at about 500 MHz so you'd need two million of them just to match one single 1 PHz fantasy device, multiplied by still another 10 billion to cut the time down more reasonably to 5.834 years (roughly 5 years, 10 months) for a cost of $200 * 10^16 (one trillion dollars is only 10^12). Conclusion: It's not really practical to attempt a crack.
  3. Direct PMOD pin access bypassing GPIO

    I've driven PMOD lines directly from HDL as part of a PWM driver to vary the brightness of LEDs when connected (via resistors) to the PMOD line jumpered onto a breadboard from one female end of a 12-to-2x6 PMOD splitter cable (the other end I reserved for plugging in a keyboard via a PMOD PS/2 adapter). It works fine to uncomment the appropriate PMOD port lines in the XDC file (and add those pin names into the entity declaration, as output in my case). In VHDL something like your problem I'd achieve by first using the clock wizard to make the initial 10 MHz clock, uncomment the desired PMOD declaration (in my case the Zybo there's six: JA through JF, I typically use JE since it has protection resistors and unpaired inputs making it more suitable for breadboarding in conjunction to the PL) and then a single signal assignment in the architecture section to drive the desired PMOD signal with the output signal from the clock. If requested I could place the PWM LEDs-via-PMOD VHDL source (only a single VHDL file, not counting XDC since these are board specific and I don't include them) on github. PS: I'll add here that it is also possible to rename the signal lines in the XDC to match the names used by an HDL project (making it easier to use a generalized project on different boards) rather than searching and replacing signal names in the project sourcefiles to match the XDC. This is likely the less error prone way and more friendly for end users of projects intended to work on a variety of boards (making it easy to upgrade to a Zybo2 or Zedboard from an original Zybo, perhaps). PSS: In the context of the PMOD documentation "GPIO", from an HDL perspective, is going to mean the PL generally (notwithstanding particular IPs that may already do so) accesses the PMOD lines directly.
  4. Lessons for kids?

    Short answer: If there is a Scratch (https://scratch.mit.edu) server that will interact between the Discovery 2 and Scratch, GET IT! It means you could plug any sort of hardware (like a temperature sensor or an IR sensor) that generates readings into the Discovery and have it send that information to the Scratch project meaning a character would be able react (say having a sprite's face go red with increasing temperature) to a signal or waveform sensed at the Discovery. This gets even more interactive if the kids make their own hardware that sends data into the Discovery (think robots). Longer answer: I'm going to take it you mean the Discovery 2 "Maker Bundle" (that has the breadboard and accessories and stuff in it). This would have similarities to Canakit's Rasberry Pi 3 "Ultimate Bundle" that includes a GPIO breakout and breadboard, jumpers and some LEDs and stuff. I'm going to be cobbling some wires up on the breadboard to exchange data between the Pi and the standard (connector JE, resistor-protected, unpaired) PMOD port. I've done some PWM stuff on the Zybo side at the PL to get warmed up and ensure my PMOD port jumpers are all in order. The Pi will basically be doing something similar what the Discovery 2 does: monitoring signals transferred over the PMOD and dumping them to a visual log (ie: waveform charts) for debugging FPGA designs. I've tried using the Vivado debug core but it fails to compile every time I try to add its IP so I've given up on that for now and will use the Pi instead. It does mean I do need a sort of mini-debug FSM coded in HDL to speak SPI over the PMOD so the Pi can ask for signal lines and the PL (as slave) will send data for the currently chosen signal(s). When making retro computers in HDL there may be a rather high number of signals to monitor, it may not be known which are needed, milliseconds take hours in simulation and the simulator does not always accurately reflect the situation on the running hardware even when using implementation-level simulation. The real joy for a younger learner with a setup like mine would be activating the Pi's GPIO server for Scratch and interacting between a PL design loaded into the Zybo and a Scratch project. All sorts of possibilities and adventures await.
  5. My first Zybo/7010 project

    Future projects may include clones of other machines or consoles (Apple II, the infamous NES, TRS-80, Amiga there are lots to choose from) and some other projects such as hardware LSTM (long short term memory, used for AI). The challenge for some will be memory (meaning I'll have to make a design that speaks AXI and uses the PS's DDR memory) since things like space for the NES game ROM memory or Amiga 500/1000 memory (including OS ROMs). The really big ones like loading a game ROM also aren't suitable for my python ROM-to-hdl script nor Vivado's RAM initialization file workflows.
  6. I thought Xilinx used bitstream encryption "for security" and to prevent leaking IP's to intruders (read: open source reversing engineers).
  7. Bitstreams tend to use proprietary formats so seeing open toolsets is somewhat unlikely over the short term.
  8. VGA Pmod Colour Pinout Change

    Any chance of making a board version where the hardwired color signals are replaced for say a 24-bit SPI (or 8-bit words on three separate SPI channels) word that would allow 8-bit color channel depth? The colors signals on these boards only allow 12-bit color which is less than the original Zybo's built-in VGA port. The onboard logic could just latch the previous color word until the SPI slave shifts in the next world completely. Of course when one starts using serial color signals it wouldn't be much of a stretch to just change to TMDS serial signalling and use the HDMI port instead (though the TMDS has lots of lookup tables and stuff that complicates the basic protocol). Edit: I'd cobble something up myself but fully QA-matched R,2R sets for 8-bit DACs are hard to come by (and three matching 0V-0.7V sets are needed).
  9. KEYBOARD INTERFACING WITH FPGA

    The first video at my "Inside the Box" YouTube channel is all about driving the Zybo's VGA. The example code (on github) is VHDL but did you know that VHDL and Verilog sorucefiles may be used together in the same Vivado project (for example even in a VHDL project a lot of the IPs have Verilog simulation sets)? For another VGA driver example, a little digging around the channel's github https://github.com/gau-veldt/InsideTheBox/tree/master/Progress_2017_12_21 and you will find the sources for the Zybo C64 and in there you'll find vic_ii.vhd -- the VHDL file for the VIC II chip. Edit: One thing I'll add here is that be sure you have downloaded the constraints file (.XDC) for the ZedBoard. Import a copy into your project (be sure to tell Vivado to make a copy into the project), open the imported file and uncomment the VGA section (also note the pin names as these are what you'll use in your entity's port declaration [sorry I don't know the Verilog analogue to VHDL's entity/port declaration]). There will be three vector signals for R,G,B and two 1-bit signals to control the H and V sync.
  10. My first Zybo/7010 project

    Greetings fellow FPGA enthusiasts! I'm looking for eyeballs Specifically digital logic enthusiasts, HDL or otherwise, and maybe even those appreciative of retrocomputing (my first Zybo project is a C64 clone after all). It is my hope I might find some people interested in this project: https://github.com/gau-veldt/InsideTheBox and perhaps also the associated "Inside the Box" YouTube channel https://www.youtube.com/channel/UCnVbLwPm8Rrd8YP44djBfoQ where I am going to attempt to explain aspects of the project to others attempting to learn. I'd like to break that feeling that I'm the only one in the world interested in these things (I know I'm not but experience and YT video visitor stats keep trying to tell me otherwise ).
  11. Zybo or Zybo-Z7 for MIPI CSI-2 experimentation?

    The I/O lines of all the Zybo's "high speed" PMODs (JB thru JD) have their protection bridges shorted to 0 ohms and adjacent I/Os routed in paired format with the intention they are used for high speed differential signalling.
  12. Heat Sink for Zybo

    I thought I once read something about a signal available at the PL that tells the Zybo's UART/JTAG driver to reset the PL (ie: same effect as pushing the reset PL button on the board)? The temp sense could drive that line appropriately and then the PL resets, the prog light goes off and the system idles like it does at power-on (prior to a PL program being loaded). All bets are off though if the PROM boot is being used or the SD boot is used (ie: not jumpered for JTAG mode). It also occurs to me that on a normal Zybo setup (no external lines, such as from PMODs, providing clocks) one may also assert the ether PHY's reset line which shuts off the master 125 MHz clock to the PL, thus also shutting off all clocks (shutting off clocks shuts off switching which is the source of the heat).
  13. My big beef with Vivado (2017) is its failure to create SDK import scripts when generating VHDL projects. (if you create a block-design-only project such as the hello world project this problem doesn't occur but currently I am more gravitated to VHDL and doing stuff mainly "under the hood" for my designs but some future designs projects may require PS interaction with the PL design to save results). This problem pops up whenever I want to use my own PL design and the ARM PS's at the same time when I do the "export to SDK" step. It can never find the "handoff" files.
  14. I chose as my first "noob" project for my Zybo's PL to make a working VHDL C64 with CPU (6510), SSM2603 audio (SID) and VGA (VICII). I started around August 2017 when I installed Vivado for the first time ever and as of now (2017.12.25) the Zybo C64 is mostly working https://github.com/gau-veldt/InsideTheBox (IEC/disk, sprites and SID filters and envelopes are on the TODO list) including keyboard which was a recent addition once I received the required PS/2-PMOD parts from Digilent. It's been quite the learning process Now the not-so-easy part: making some videos of various aspects of this design for my YT channel. To say xilinx has a lot of reference manuals is understating it - they have a TON of manuals. The hard part is finding which manual applies to the problem one is having. Digilent also has some useful manuals, particularly for PMOD accessories. For things like the Zybo some external data sheets are also of import, such as those for the SSM2603 (Zybo's audio chip) and tinyvga.com is a good one for getting the needed settings to have various video modes at the VGA port.
  15. Also note if you have a YT channel, a domain name or anything of that sort, those could be considered as names connected to your "business" -- a sole proprietorship run by yourself.