zygot

From your too brief description of what you want to do, I don't think that you've started with the right question. What DAC are you intending to use? Usually, Digilent FPGA board reference manuals include a statement about the standard PMOD supporting a 10 MHz toggling rate. This might be sufficient for estimating what kind of applications an individual pin could be used for, but not necessarily what any two or more pins might be used for, as is the case for a project such as yours. Most of Digilent's boards are designed to be used with standard PMODs and are not designed so that the typical user can create a custom interface for this kind of application. In theory, for a lot more investment a Digilent board with SYZYGY or FMC connectors could support your project but designing and building custom add-on boards for these connectors is beyond the ability of the typical person and expensive. I don't know of any 200 MHz SYZYGY DAC pods, though the specification would certainly support a 200 MHz DAC of some type. FMC mezzanine cards are not cheap. You can certainly work out a usable toggle rate for any Artix device from the datasheet but device performance isn't the same as board performance.

There's no harm in experimentation... well at least not if it's knowledge based and takes all relevant parameters into consideration. ( and knowing what that means involves a bit of knowledge ) The first step is to read the relevant material for all components involved. Start with ug471. In general FPGA inputs are a bit safer and easier than outputs, as long as the FPGA pin isn't exposed to excessive voltage levels. One way to expose your FPGA pin ( input or output ) to excessive voltage levels is through ESD. FPGA devices, and in particular FPGA development boards, aren't necessarily the ideal route to someone not particularly interested in embarking on a self-directed educational journey in order to complete a project. There are PSoC devices and boards as well as traditional uControllers that might make more sense. I'd be surprised if you couldn't find that something along the lines of what you want to do exists in the RPi or Arduino ecosystems. Your project, in particular, is probably not one well suited to a programmable logic solution; unless you are an expert in FPGA design and just want to try out an new challenge that is a bit more expansive than basic FPGA development. I'm getting the sense that you are more interested in doing a software project than a hardware project. Understand that Digilent FPGA development boards, for the most part and like most low cost FPGA development board vendors, are designed to be used within a limited and controlled add-on board ecosystem; in Digilent's case this is PMOD related boards. Unfortunately, Digilent's support of their ecosystem isn't consistent for everything in it. So, as a customer I'd first want to know if their products and support provides a solution to my project. Customers with advanced skills can often, but not always, figure out a way to use an FPGA development board to accomplish what an ecosystem doesn't. My assumption is that someone with those advanced skills knows how ascertain what the required questions to creating a custom solution are and are generally able to find answers for themselves. Not having the pertinent advanced skills is only a problem if you don't have the time or interest in acquiring them.

You need the schematics for your board and a read through of ug471; this will allow you to select an IOSTANDARD and possibly a termination scheme. Vendors of photo diodes usually provide application notes for such components. If you have a packaged APD product then you need technical information from that vendor. Impedance matching is just one aspect of a workable design. Digilent standard PMOD pins have a 200 ohm series protection resistors and likely not an optimal trace routing that complicates such a design and limits bandwidth. The so-called differential high-speed PMOD pins have no series resistors and possibly improved trace routing. The there is the matter of what's between your ADP and the PMOD pin in terms of wiring and power supply. Your choices are likely between finding a suitable 3.3V CMOS or TTL per-fabricated product or developing some expertise in logic/analog design. In theory it should help if you are an EE but such formal preparation is by no means a requirement. Either way, you need to have a good understanding of how your sensor interface works to achieve robust results.

It's depressingly often that I resort to a 2 board solution to complete a project. I've posted a possible solution to an asynchronous full-duplex board-board data interface here: https://forum.digilentinc.com/topic/20479-inter-board-data-transfer-project/ that uses the high speed PMODs. You can always roll your own. It's a shame that finding FPGA boards with more than 1 Ethernet PHY at reasonable price is hard; but that's the way it is. The $199 MAX 10 Development board has 2 such PHYs. It unfortunately uses a stacked RJ-45 connector. I've been able to use either one seeparately, but not both together; my working assumption is that it's a board design issue. This would make for an ideal platform for your project... if it worked. Terasic makes a dual 1 GbE HSMC card that would work but this isn't cheap. Affordable platforms providing 2 or more Ethernet PHYs are hard to come by. I've told you about what I think of spending more time on an ENC24J600 SPI effort. Unfortunately, Digilent is dead set on a commitment to the very outdated 12-pin PMOD ecosystem so implementing an ENC24J600 interface that's worth the effort isn't possible. [edit] PS Take care when connecting two boards with separate power supplies into one functional unit.

There is plenty of Digilent IP and project source code available to help guide you with this. And hierarchical HDL is a basic level skill. Browse the Digilent Forums, the Digilent support resources, and Xilinx resources using the Documentation Navigator for example designs. You'll find that stuff posted in the Digilent Project Vault ( if you ignore all of the stuff that should be in some other forum ) might be written in a form that is more accessible to someone learning an HDL.

Well, that's fine and well for you. Here's what both you and I know so far. Digilent either can't or isn't inclined to provide the same resources for the NIC100 that it does for most of it's PMODs so that should be informative. If you want to figure this out one your own, then get the ENC24J600 datasheet, create your own ENC24J600 SPI compatible AXI interface ( assuming that you are using either a ZYNQ device or soft processor that ideally would be software compatible with the ucontroller that the library was created for ) and do the work yourself. I once planned on creating a universal interface suitable for the typical PMOD equipped platform and after a few days of looking it over decided that it wasn't worth the effort. Could that be the same conclusion that Digilent has arrived at? True Etherenet PHY based interfaces don't require any software to implement basic functionality. This isn't necessarily the case with the NIC100. Digilent's marketing of this product seems a bit disingenuous to me. The fact that their position is, hey we have this nice library created for a controller so go ahead and buy the product for use with your FPGA board and see what you can do with is isn't much help in mitigating that viewpoint any... Marketing people are supposed to be optimistic. But when a company markets to a predominately student and hobbyist consumer optimistic can quickly veer into the unethical sphere; so what is mentioned in the marketing of a product, and more importantly what is not mentioned is extremely important. At least that's how I see things. BTW both of your platforms have functional Ethernet PHY interfaces.

If you are hoping for 100 Mbps data rates from this device you better read and understand the ENC24J600 datasheet. The device has a few interface options that might support that speed, but the SPI interface isn't one of them. This depends on packet size, packet rate, and whether your connection is full duplex or half duplex. It's an odd device. Suggesting that the NIC100 will support 100 Mbps is a bit sketchy in my view.

Oh, that APD FPGA devices have pins connected to IO banks that can be powered by a range of voltages. Depending on the bank Vccio voltage you can use pins tied to these IO banks with a selection of various logic families found in devices that you might want your FPGA to interact with. The guide for Xilinx Series 7 FPGA IO pin logic is ug471. An Avalanche Photo Diode is not a member of a logic family. There are a lot of traditional logic families and sub-variants that were developed over the years. Logic that drives signals have characteristics like output impedance (current drive capability) and a few more specifications. For single-ended logic that drives a signal, certain additional characteristics are important; like slew rate, guaranteed max/min output voltage indicating a logic 1, guaranteed max/min output voltage indicating a logic 0, etc. For single-ended logic that receives signals there are mirror characteristics to be considered. For receivers the min/max voltages for logic 1 and logic 0 are extremely important. Typical programmable logic can be used with a few but not all traditional logic families depending on the voltages supplies to the IO banks. Ideally, when connecting logic drivers to logic receivers ( FPGA devices or whatever ) you want to match receiver impedance to the driver impedance, and usually connect them via wires that have the same effective impedance. This part of logic design can get pretty complicated. Some single ended logic families require specific termination schemes. All may require some type of termination scheme depending on the slew rate and toggle rate that the signal exhibits. As you probably know, impedance involves more than just resistance and is frequency dependent. One can view the connections between logic driver and logic receiver as a transmission line with a bandwidth range dependent on driver slew rate. This view might be important for pulsed signals. Understand that slew rate for logic signals going from 0 --> 1 are not always the same as for signals going from 1 --> 0. It may not be obvious, but most traditional single-ended logic receivers have voltage regions that are not defined as either a logic 1 or a logic 0. You can read the datasheet for a traditional logic device for the details. Connecting drivers to receivers is a topic of study in its own right. Given that a diode lacks a driver exhibiting controlled characteristics designating binary values as described above you should expect that a bit of logic interface design is necessary to connect it to a traditional logic device, including an FPGA. Even traditional logic families have characteristics that are only guaranteed over certain temperature spans and logic power supply spans. This is an additional complication for what you want to account for if you want consistent results. So, what you need is a logic design that turns the output of your APD into something that is compatible with one of the available IOSTANDARD for a given pin on your board.

What's an APD? Can you be more specific about the external logic type coming into your FPGA board; such as minimum pulse width, repetition rate, logic family, etc.

The place to get that information is in the Genesys2 data sheet. Fortunately, the Genesys2 has a HPC ( High Pin Count) FMC connector and there are more than 36 LVDS pin pairs available, plus M2C and C2M clock pairs. Assuming 2 bytes/sample at 1.2 GS/s this would imply a 2400 MB/s data rate. Assuming simple DDR LVDS across 36 channels this comes out to about 67 MB/s (533 Mbps ) per channel which is well within the Kintex -2 abilities. It's also within the Genesys2 DDR3 maximum read/write capabilities, which I've measured at close to 6 GB/s. Be aware that operating the DDR3 at the maximum data rate and connecting other interfaces to your data might involve some agony meeting timing closure. There are still things to consider. It's unlikely that all 42 LVDS pairs on the Genesys2 FMC connector are length matched sufficiently for a parallel 36 channel bus. Fortunately, you can tune the pair delay skews using IDELAY. This might involve considerable work. A significant detail to resolve is clocking. Make sure that you understand the Series 7 Select IO and Clocking Reference Manuals and do your due diligence before committing to an FPGA platform. The Genesys2 borrows heavily from the KC705 which has both LPC and HPC FMC connectors. This is vitally important if you aren't designing your own ADC FMC mezzanine board but purchasing an off the shelf evaluation board. There are a myriad of things to understand for most high speed ADC EVB design depending on your application in terms of analog performance. A further issues is what to do with the samples post acquisition. The KC705 would allow you to connect an FT601 USB 3.0 interface. With the Genesys2 you would be stuck with either the Etherent or 30 MB/s USB 2.0 port. You could use the KC705 PCIe 8 lane Gen2/Gen3 interface as an option for moving samples to a PC. The major caveat I see with the KC705 is that there are so many spins of the board and documentation is pretty poor. The last KC705 that I bought was unable to configure the Kintex device after about 5 months of use and the company that could fix it wanted about what the board cost just to ficure out what was wrong. The power supply design on the KC705 is a mess and I've had issues with both of the boards that I've owned. I can say that I still use the first one even though I've destroyed the PCIe transceivers. But personally, I don't trust KC705 boards built in recent years. Except for documentation issues, that are mostly resolved I haven't had problems with the Genesys2 boards.

You can simulate a design with unconnected signals but you can't implement it. If the tools can't connect toplevel signals to an IO pin there's no implementation or bitstream. What you might be able to do is connect your IO to VIO IP and use the Hardware Manager to set and detect signals. You might connect them to a UART or some other physical interface.

I still use WIn7 and Adept to program my Genesys as an Ethernet Tester when checking out the PHY interface on another board. Perhaps you have host related issues, like a hard disk issue. Win7 hasn't been supported for while so my box never sees a network; but unlike me software shouldn't get old and crotchety. Hardware? Now, that's a bit more likely.

It's sad but among the things that Xilinx sees fit to muck with, from version to version, is syntax for constraints. If you read the warning messages I bet you'll see a bunch of warnings about ignored constraints due to syntax errors. You can use the tcl console to get help with syntax ( sometimes you'll get suggestions that the tools will accept... ) or use the template tool. Vivado help is not always up to date with tool. If this fails you can try web searches. It's easy to ignore warning messages as there can be hundreds of them, most ignorable, but then there are the ones that point to a serious issue; not all of these cause a bitgen failure but still produce broken implementations. So, be in the habit of reading what the tools have to say. You won't be happy unless the tools understand your instructions; at least the tools try and tell you when it's confused about its marching orders...

Simply comment out any constraints for unused pins, by inserting the '#' character at the beginning of the line. I tend to create a new constraints file from the master constraints file that only references pins used in the design. As I recall the Digilent master constraints files come with all constraints commented out, so you could just start with copying the master constraints file for your board to a new file and commentating those that apply to your toplevel entity or module. Not all vendor tools throw an DRC error for constraints that aren't connected to a design, but Vivado does.

I still use Vivado 2019.1 for other reasons for a about half of my project development; this includes ZYNQ and al HDL projects for various reasons. Eventually I will have to use VIvado 2021.2 for non-Linux ZU7EV development but so far this hasn't been necessary. I have used Vivado 2021.2 for ZU7EV HW design. Still haven't done a Vivis software project. If your design uses the MicroBlaze IP then it's unlikely that transitioning back to a previous version will not entail a bit of effort. If all you want to do is use a UART to set some register values in a logic design you don't need a soft processor. Most of my designs use either the on-board UART or a separate TTL USB UART cable to write and read registers from a PC. There are examples of Verilog and VHDL UART implementations available on the Digilent Forum. Be aware that writing binary data through a UART isn't straight-forward; but you can always send two ascii characters to represent an 8-bit hex value. Using this approach allows you to use a simple Serial Terminal application to interact with your design. Yes data transfer is half as fast but at 921600 you can't type fast enough to notice. All of my project use this method, at some point. No SDK or Vitis needed. Since you are starting out you might just want to consider learning how to use Vitis if you must use the Xilinx soft-processor IP. For your board, there's no compelling reason to download 40+ GB of installer data to use Vivado 2019.1. I'd go with the earliest version of Vivado that supports the device and package on my board if doing just an HDL design; you can save yourself at least 80% of the disk space and install time. Perhaps it might be worth the cost of a really cheap ZYNQ board for you to do what you want easily. See the following link: https://forum.digilentinc.com/topic/22512-manipulate-pl-logic-using-ps-registers/ Sometimes you want to learn a proper FPGA development flow and sometimes you just want to get to working on the stuff that interests you, Time is expensive so do the analysis. A design/development strategy that works best for me might not be one that works best for anyone else. Assess your skill level and be flexible with an approach.

Sounds so inviting. Windows can handle 921600 COM devices without flow control and long data transfers, as do several Serial Terminal applications that run on the OS. At faster baud rates things get ugly pretty fast. FTDI USB UART bridge devices support baud rates to 3 or 12 Mbaud depending on the device, but the Windows VCOM drivers will not let you go above the 921600 mark. You can buy an FTDI UART Bridge module and convert it to a D2XX driver compatible device, but using the higher baud rates will still require hardware flow control and using the FTDI D2XX API libraries. You are hoping to bootstrap a Xilinx demo using the USB port as a 115200 baud ( as I read the article ) and a Win 2000 32-bit driver for which you have no source, API, or even capability description at 40 Mbaud? This doesn't sound promising to me. UART devices are pretty straight-forward. UART over USB is anything but straight-forward, especially if you want to use high baud rates. I'm not saying that the USB3320 USB 2.0 can't be useful for Win**** platform communications but make sure that you have all of the parts before venturing too far into a commitment. Window is just not a DYI friendly OS environment nor do the tools provide an easy cost-free path for custom driver development.

There are a lot of AXI options for connecting a design implemented in the PL to your ARM processors, depending on whether the ARM controls the bus or the PL design controls the bus. Be aware that the UltraScale ZYNQ is a much more complicated beast than the Series 7 ZYNQ devices. Before moving ahead you need to read through the ZYNQ UltraScale TRM to gain an understanding of the differences. Unfortunately, the Xilinx tools are moving in the direction of abstracting user control of the logic resources and IP. When things go as planned this might be nice, but when things go badly its a big problem for the developer. Having the tools work out the details ( and hiding it behind encrypted source ) is like a two edged sword... or perhaps I should say like being a passenger in the back seat of a self-driving car; when the technology is working well you might have a nice experience. When the technology fails, you might want to be somewhere else in the moment. I'm making the assumption that the HLS tools are more attractive to people wanting to add custom functionality to the PS without significant external interface logic design. For those wanting to implement high performance interfaces to external hardware the regular tools might be more appropriate. The UltraScale IO has changed significantly from the Series 7 devices and entails a lot of new skills except for the most trivial single-ended signals. Migrating from Series 7 to UltraScale using advanced IO resources is not a trivial endeavor. Even a simple RGMII implemented in HDL is challenging, based on my personal experience.

I don't understand what you are trying to do. To enable the PS connected DDR4 just enable in in the ZYNQ UltraScale+ block. This allows the PS to access the external memory on your board directly. You can use the PS/PL AXI ports to allow a design in the PL to DMA data into or out of the PS memory if desired. What is the DDR4 SDRAM block supposed to be connected to? It can't be the PS connected DDR4 memory because that's connected to the PS MIO pins. Even if you could mux the PS external memory controller pins through the EMIO to a PL design, why would you want to? The PS hard external memory controller is going to be higher performance and use no PL resources. Your block diagram doesn't appear to be the toplevel module in your project so it's hard to see what you are trying to do without the source and associated constraints. UltraScale(+) devices have their own version of the Series 7 and earlier MiG soft external memory controller IP for logic connected external memory. This IP provides different options for IPI instantiation relative to native HDL instantiation. If you have external memory physically connected to PL pins then you can instantiate a soft logic controller to use it and Xilinx will force you to use the AXI resources. I don't see a point in this arrangement so for the ZCU106, which does have PL connected DDR4 memory I create a basic IPI with nothing but a preset ZYNQ UltraScale+ block and use a wrapper to connect the block diagram generated sources to my toplevel source. For DDR4 soft IP controllers you can't assign arbitrary external clock pins to the controller due to the tight timing. More importantly, UltraScale ZYNQ memory use is more complicated than the Series 7 ZYNQ so there might be good reasons to isolate any PL connected external memory from direct PS access. Do read the ZYNQ UltraScale+ TRM. NOTE: You seem to be using the HLS tool which I don't have experience with ( you should make that clear from the beginning ). Even so, the device architecture and resources are the same regardless of the tools use to create a bitstream, so I think that my comments are relevant. A problem with the HLS tool is that it's suppose to hide the messy details of FPGA design, which causes it's own problems and confusion when things don't work out.

Your board doesn't have any DDR memory connected to PL pins, so the only way to access the PS external memory would be through the PS/PL AXI ports. It is no possible to have the PS external memory controller and a PL based memory controller control the same memory. You say that you've done this for the ZYBO, but the same answer applies to that board as well. There aren't many ZYNQ boards having two separate DDR banks, one connected to the PS and the other connected to the PL. The ZCU106 is an exception, as both sides of the ZYNQ hardware have their own external memory. BTW UltraScale doesn't use the Series 7 MiG IP for external memory controllers; this family has it's own external memory controller IP. Timing for DDR4 is very tight, limiting clocking options, unlike DDR3 controller IP.

Read your constraints file again; you've only set constraints for the MDI pins. ALWAYS check the post implementation pin report to ensure that pin location and IOSTANDARD constraints are correct before trying out a bitstream on hardware. [edit] Always make sure that every signal in your toplevel source file has a valid pin location constraint. The tools will assign random pin locations to anything not explicitly defined. So, perhaps you will "get lucky" and an output will not be assigned to a pin already connected to an external device with an incompatible logic standard, or ground... and perhaps you won't so lucky... Always, always double check to make sure that your FPGA pins aren't assigned to the wrong pins before configuring your device. "'I'd like to use the PHY MDI interface to have some customization on the Ethernet interface on the Genesys2 and create some custom cores with higher level stacks like UDP, TCP/IP without using ready-made IP cores. " This is a worthwhile project for someone with more advanced skills in Verilog development, something I don't see in your coding samples. There isn't much functionality, other than statistics and status conditions ( none related to packet structure ) in the PHY since it's really just a cable modem. You should be able to implement any packet type that you desire in your custom core sources for 1 GbE speeds without touching the PHY on the Genesis2. If you want to support slower speeds than you will need to use the MDI, but you could certainly develop your ideas without this.

This is a great example of why no one should throw together some code and try it out on hardware and see if it works. ( not just because you are making this too hard, but because you can actually damage your hardware in this case ). My suggestion is that you get your MDI interface working in simulation. This means writing at least an RTL testbench, and possibly a behavioral one. It also means writing a Verilog source that simulates how you believe, from reading the datasheet, the MDI on the RTL8211 responds. Obviously, this entails getting the RTL8211 MDI code working before trying to do read and write operations with your interface. It wouldn't be unreasonable to combine the RTL8211 behavior in the testbench, but I'd advise against it. You might have some difficulty with HiZ logic levels in simulation, depending on how you go about coding your design modules, but it's an essential skill. You may think that all of this simulation effort is a waste of time, but in reality the exercise will illuminate your understanding of what is going on and save you time. More important this is just the proper way to do programmable logic development in a professional manner. It's also the most effective way to develop your skill as an FPGA developer. There are subtle details that even a decent ( but not quite correct or complete ) simulation effort can trip you up. For instance having the PHY in reset while trying to use it. You've the start of an idea. You just gave up too soon because you want to bypass correct design processes. I could post working code. You could just find some on your own. None of those would be fair to you because it would encourage bad design behavior. This is a pretty good basic HDL project for someone with low to moderate Verilog skills wanting to advance. Is there a reason why you need to use the PHY MDI interface?

Warning!!! Purely Editorial Post in Progress!! It's hard to read a post like the one above by Lexis without inferring a tone of indignation that he, not the original poster, has been failed by inattentive people providing useless answers to simple questions. Sometimes, while reading stuff posted to threads about technical questions I have a recurring daydream about starting a non-profit to aid the plight of the poor schlubs who have the audacity to post answers to such questions. If you are in the western world ( and who isn't, depending on where you sit? ) you've seen the ads begging for donations to save the whales, save the children, save the puppies... etc etc. I have to admit that when I see these ads by billion dollar organizations carefully orchestrated to communicate directly to the primitive brain, bypassing the conscience brain, I tend to wonder who it is exactly that is being abused.... and poof, the daydream is over. Anyway, my point is that what's obvious to one person isn't so obvious to another person. We all know the danger of offering unsolicited advice, but occasionally trying to help when help is specifically requested results in responses that are discouraging, to say the least. Don't pity the idiots posting answers to questions, but do try and comprehend the complexity of trying to communicate ideas. The whole post a question, get an answer becomes a bit warped when the question is more about completing a homework assignment than discussing technical hurdles. BTW Do donate time and money to worthy causes... just do your homework to make sure that a significant portion of your contribution is actually being used for what you expect it to be...

You mean this: "I wish to use the connector labeled UART (J14) to send and receive the bits." ? ( on my Zedboard the connector labeled UART is J13 ) Since this UART is connected to the PS through the MIO pins it implies that that the design requires a separate PS/PL connection. But you are correct that you can certainly create a ZYNQ PL design that the PS has no knowledge of; just implement a UART in your HDL and connect the TxD/RxD pins to a PMOD connector, and those to a USB UART Bridge device. I much prefer using a USB TTL UART cable or breakout board but the solution that you mention will work as well. Of course, this means purchasing additional hardware. Were this question posted more recently, I'd probably point them to this: https://forum.digilentinc.com/topic/22512-manipulate-pl-logic-using-ps-registers/ No additional expense required. I don't share your certainty about what the initial poster was looking for, but I do believe that suitable answers were provided, though perhaps not directly. Since there were no follow-up posts it's reasonable to assume that the original poster figured out his solution based on the responses. Rarely are questions posted to this forum as clear as some readers might assume. Sometimes it takes a conversation to resolve questions satisfactorily.

I've used just about every version of Xilinx tools since they've been making programming logic and I'm frequently frustrated and disappointed by each version... so all is normal. ( same goes for the Intel tools which have gotten worse in the hands of Altera's new owner ) Vivado/Vitis is the tool set so get friendly as best you can. Don't assume that a newer version is better than an older one for older devices like yours. Perhaps you could try and describe specific issues that you are having; this will likely produce useful responses. Do use the Document Navigator tool that gets installed with Vivado and read the tutorials and reference manuals for your device and the tools. Xilinx is not great at keeping the documentation up to date but might be more helpful than the Vivado/Vitis built-in help. The tools are complicated, as are the design and development flows, so jumping in without preparation might not be a good idea.

If you need a robust long-term solution to operating a board outside it's "normal" operating conditions, the only realistic way to address the problem is by encasing it in a box and controlling the environment inside of that. Certainly there are additional problems introduced with this approach. Of course, adding heat is generally a lot easier than dissipating heat, which is what you have to do. Over time, there are a lot of things that could go wrong; right down to the behavior of the solder used to connect the parts to the PCB. I'm assuming that you want to use your boards over extended periods. Trying to address pieces of the problem of high temperature operation by waiting to observe obvious failure conditions is not a good long term strategy. Have you considered an alternate approach to data management other than the SD card route? Perhaps there's a way to "cheat" the system ( that is reality ) ... When one approach to a problem, as defined by some "arbitrary" box, isn't working it might be reasonable to change the definition of the box. This depends on the the requirements of the task at hand, but sometimes the requirements aren't as concrete as we assume; hence the term "thinking outside the box".