<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jul 7, 2017, at 4:07, David Summers <<a href="mailto:jcore@davidjohnsummers.uk" class="">jcore@davidjohnsummers.uk</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:A8969A99-72CA-4E34-A7B8-FF7621EDECD4@SE-Instruments.co.jp" style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=""><pre wrap="" class="">Which is why this looks very different. We don't use anything the vendor requires, because that locks in the vendor. The synthesis tools are wrapped in Makefiles, and you can replace them with another toolchain. This is not a Xilinx, S6 (or A7) board. It's a board that happens to use an S6 to carry the J-Core SoC. Some of our customers use K7, it will be available on a TSMC process soon... Nothing we can't replace can be used.
</pre></blockquote><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class="">Confused. Though you had to use Xilinx tools to build the bitsteam. Its going to be hard to escape from using manufacturer tools for converting VDHL/Verilog into something that can program a FPGA (whoever makes it).</span><br style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);" class=""></div></div></blockquote><div><br class=""></div><div>Yes, this is true. The point is to not use anything that ties you to the vendor tools, such as hard macro blocks, their JTAG tools, etc. For instance, almost every design that uses DDR memory on Xilinx uses their memory generator tool. We have a complete controller that only uses their DDR I/O cell (which is not a problem to replace on any technology). We have wrappers for just about everything, but still the implementations of things like register files is as portable as possible. None of the tool features are used, if they cause vendor lock.</div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class="">But surely this is just a tool for developing j-core devices. And once you go onto an ASIC, you'll be tied to the process that is used for the layout of the ASIC.</span></div></div></blockquote><div><br class=""></div><div>No, that is strictly avoided, we are portable RTL just about everywhere. We either design hard macros (LVDS, register files...) or license them (SRAM blocks, PLL) but it has to be generic stuff. e.g. our high speed SERDES transceivers that taped out at 180nm (deep N well process for low noise analog) required a little redesign for 152nm (85% shrink), and SRAM is always a pain. Everything else, we are completely process portable.</div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><span style="font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class="">But you will end up witha chip based on an open VHDL, against which it can be to verify how the chip is coded.<span class="Apple-converted-space"> </span></span></div></div></blockquote></div><br class=""><div class="">Exactly :).</div><div class=""><br class=""></div><div class="">But keep in mind I didn't say we don't support JTAG, or that you -can't- use Turtle to develop RTL. The AVR on the Turtle is connected to the JTAG, and you can use it that way if you write a driver for it. We use urjtag and gdbproxy through a JTAG TAP for debug to the J-Core CPUs. It goes through the S6 BSCAN macro block, or you can instantiate an RTL TAP controller and use regular pins. There is no reason you can't use the JTAG program the SPI flash, for instance, should you brick the AVR. I've not had to use a JTAG cable, even for RTL development, for 3-4 years I would guess...</div><div class=""><br class=""></div><div class="">On chip logic debug is easy to do also... just instantiate an on-chip logic analyser. You could connect it directly to the J-Core CPU bus, or even something like this connected to an on chip UART: <a href="http://hamsterworks.co.nz/mediawiki/index.php/CheapScope" class="">http://hamsterworks.co.nz/mediawiki/index.php/CheapScope</a> You don't even need a USB UART, just compile the control software to run on the J-Core Linux on the board, ssh over and do your logic debug right on the target...</div><div class=""><br class=""></div><div class="">I think it's important to note, all this stuff is very mature, and in production use. Turtle is an open project, but that doesn't mean that it itself is experimental, all of the circuitry, RTL (J-Core itself, peripherals, DDR, Ethernet...), tools (including the AVR supervisor USB MCU), SW toolchains, uClinux OS, etc. is in daily use in mission critical infrastructure applications. That is why J-Core exists, and also why the open side is slow moving at times... we use it in our day jobs :)</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">J.</div></body></html>